Oracle® DIVAnet

Guide d'installation, de configuration et d'opérations

Version 2.1

E77645-01

Juin 2016

Guide d'installation, de configuration et d'opérations Oracle DIVAnet, Version 2.1

E77645-01

Copyright © 2016, Oracle et/ou ses affiliés. Tous droits réservés.

Auteur principal :  Lou Bonaventura

Ce logiciel et la documentation qui l'accompagne sont protégés par les lois sur la propriété intellectuelle. Ils sont concédés sous licence et soumis à des restrictions d'utilisation et de divulgation. Sauf stipulation expresse de votre contrat de licence ou de la loi, vous ne pouvez pas copier, reproduire, traduire, diffuser, modifier, accorder de licence, transmettre, distribuer, exposer, exécuter, publier ou afficher le logiciel, même partiellement, sous quelque forme et par quelque procédé que ce soit. Par ailleurs, il est interdit de procéder à toute ingénierie inverse du logiciel, de le désassembler ou de le décompiler, excepté à des fins d'interopérabilité avec des logiciels tiers ou tel que prescrit par la loi.

Les informations fournies dans ce document sont susceptibles de modification sans préavis. Par ailleurs, Oracle Corporation ne garantit pas qu'elles soient exemptes d'erreurs et vous invite, le cas échéant, à lui en faire part par écrit.

Si ce logiciel, ou la documentation qui l'accompagne, est concédé sous licence au Gouvernement des Etats-Unis, ou à toute entité qui délivre la licence de ce logiciel ou l'utilise pour le compte du Gouvernement des Etats-Unis, la notice suivante s'applique :

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government.

Ce logiciel ou matériel a été développé pour un usage général dans le cadre d'applications de gestion des informations. Ce logiciel ou matériel n'est pas conçu ni n'est destiné à être utilisé dans des applications à risque, notamment dans des applications pouvant causer un risque de dommages corporels. Si vous utilisez ce logiciel ou matériel dans le cadre d'applications dangereuses, il est de votre responsabilité de prendre toutes les mesures de secours, de sauvegarde, de redondance et autres mesures nécessaires à son utilisation dans des conditions optimales de sécurité. Oracle Corporation et ses affiliés déclinent toute responsabilité quant aux dommages causés par l'utilisation de ce logiciel ou matériel pour des applications dangereuses.

Oracle et Java sont des marques déposées d'Oracle Corporation et/ou de ses affiliés. Tout autre nom mentionné peut correspondre à des marques appartenant à d'autres propriétaires qu'Oracle.

Intel et Intel Xeon sont des marques ou des marques déposées d'Intel Corporation. Toutes les marques SPARC sont utilisées sous licence et sont des marques ou des marques déposées de SPARC International, Inc. AMD, Opteron, le logo AMD et le logo AMD Opteron sont des marques ou des marques déposées d'Advanced Micro Devices. UNIX est une marque déposée de The Open Group.

Ce logiciel ou matériel et la documentation qui l'accompagne peuvent fournir des informations ou des liens donnant accès à des contenus, des produits et des services émanant de tiers. Oracle Corporation et ses affiliés déclinent toute responsabilité ou garantie expresse quant aux contenus, produits ou services émanant de tiers, sauf mention contraire stipulée dans un contrat entre vous et Oracle. En aucun cas, Oracle Corporation et ses affiliés ne sauraient être tenus pour responsables des pertes subies, des coûts occasionnés ou des dommages causés par l'accès à des contenus, produits ou services tiers, ou à leur utilisation, sauf mention contraire stipulée dans un contrat entre vous et Oracle.

Table des matières

Liste des tableaux

Titre et informations de copyright

Préface

- Accessibilité de la documentation

1 Introduction

- Présentation du système

- Prise en charge d'API

- Interface utilisateur (DIVAnetUI)

- Interface de ligne de commande (DIVAnetAdmin)

- Règles d'accès

- Autres composants DIVArchive

2 Planification de l'installation

- Présentation de la connectivité de site

- Services DIVAnet

- Activation des sites pour l'accès distant

- Service ManagerAdapter de DIVAnet

- DIVArchive

- Objets et instances

- Source et destinations

- Configuration des sources/destinations de transfert

- Média (de stockage) et plans de stockage

- Drop Folder Monitor (DFM)

- Configuration de l'accès client local

- Service ClientAdapter de DIVAnet

- Service DbSync de DIVAnet

- Sites en lecture seule

- Base de données DIVAnet

- Nettoyage d'objet

- Compatibilité des versions de DIVAnet

3 Installation de DIVAnet

- Tâches préalables à l'installation

- Installation du logiciel DIVAnet

- Installation de DIVAnet sur Windows

- Installation de DIVANET sur Oracle Linux

- Création de la base de données DIVAnet

- Création des tables

- Création du schéma de base de données DIVAnet

- Suppression du schéma de base de données DIVAnet

- Chaîne de connexion Oracle

- Ajout de sites

- Création des fichiers de configuration DIVAnet

- Installation et démarrage des services DIVAnet

- Installation des services DIVAnet pour Windows

- Installation des services DIVAnet pour Linux

- Gestion des services DIVAnet sur Linux

- Affichage des journaux

- Vérification de la configuration

- Synchronisation de la base de données DIVAnet

- Mise à niveau de DIVAnet

4 Configuration des services DIVAnet

- Configuration du service ClientAdapter

- Configuration du nom de site de DIVArchive

- Configuration des ports API client

- Configuration des connexions Web client

- Configuration des profils de workflow

- Profils et ports API

- Nouvelles tentatives et expirations de délai

- Messages valides

- Mappages de site à site

- Rechargement des profils de workflow

- Modification du fichier de configuration de ClientAdapter

- Paramètres de niveau supérieur

- Section des ports API

- Section des Managers DIVArchive

- Section de base de données DIVAnet

- Section de profil de workflow

- Mappages de transfert site à site (profil de workflow)

- Mappages source/destination préférés

- Configuration du service ManagerAdapter

- Filtrage synchronisé par catégorie

- Configuration de la substitution de préfixe de catégorie

- Modification du fichier de configuration ManagerAdapter

- Configuration du service DbSync

- Modification du fichier de configuration de DbSync

- Section DivaManager

- Base de données DIVAnet

- Configuration des règles d'accès

- Méthodes d'exécution des règles d'accès

- Exemple d'archivage

- Exemple de copie

- Règles d'inclusion et d'exclusion

- Types d'attribut

- Règles pour les demandes DIVAnet (ClientAdapter)

- Opérations Connect

- Sous-type (pour suppression)

- Règles pour les demandes DIVArchive (ManagerAdapter)

- Mise en correspondance de règle

- Jeux de règles et valeurs par défaut

- Autre exemple

- Paramètres de jeu de règles

- Paramètres de règle d'inclusion ou d'exclusion

- Ajout de variables de script à un fichier de configuration

5 Utilisation de l'interface utilisateur DIVAnet

- Prérequis

- Démarrage de l'application DIVAnetUI

- Connexion à DIVAnet

- Affichage des actifs

- Panneau Asset Details

- Recherche d'actifs

- Couper et coller des détails d'actif

- Affichage des demandes

- Affichage de la progression des demandes (mises à jour live)

- Affichage des détails de demande

- Annulation de demandes

- Filtrage des demandes

- Couper et coller des détails de demande

- Copie d'un objet

- Suppression d'un objet

- Restauration d'un objet

- Modification du fichier de configuration

6 Administration de DIVAnet

- Utilisation de l'utilitaire DIVAnetAdmin

- Traitement et mise en file d'attente des demandes

- Mise en file d'attente de demandes DIVAnet

- Limitation des demandes DIVAnet

- Nouvelles tentatives de demande DIVAnet

7 Prise en charge d'API

- Compatibilité de version d'API DIVAnet

- Opérations sur du contenu archivé

- Demandes d'archivage

- Demandes de restauration

- Workflow de restauration

- Sources et destinations

- Nouvelles tentatives

- Restrictions

- Demandes de restauration de fichiers partielle

- Demandes de copie

- Méthodes de transfert de site à site

- Copies locales

- Sélection par DIVAnet (média avec la valeur any)

- Nouvelles tentatives

- Demandes de suppression

- Suppression de site (média avec valeur any)

- Dernière instance

- Nouvelles tentatives et annulations

- Autres commandes prises en charge

- Demandes non prises en charge

- Codes de retour

8 Dépannage

A Exemples de fichier de configuration

- Exemple de configuration ClientAdapter

- Exemple de configuration ManagerAdapter

- Exemple de configuration DbSync

Glossaire

Liste des tableaux

- 2-1 Services DIVAnet

- 3-1 Services DIVAnet sur Linux

- 4-1 Paramètres de niveau supérieur de ClientAdapter

- 4-2 Paramètres de ports API

- 4-3 Paramètres de configuration de DivaManagers

- 4-4 Paramètres DIVAnetDatabase

- 4-5 Paramètres WorkflowProfile

- 4-6 Paramètres de profil de workflow SitetoSiteTransfer

- 4-7 Paramètres de niveau supérieur ManagerAdapter

- 4-8 Paramètres ManagerDatabase

- 4-9 Paramètres ObjectFilter

- 4-10 Paramètres de niveau supérieur de DbSync

- 4-11 Paramètres DivaManagers pour DbSync

- 4-12 Paramètres DIVAnetDatabase

- 4-13 Paramètres de jeu de règles

- 4-14 Paramètres opérationnels de règle (d'inclusion ou d'exclusion)

- 4-15 Paramètres de demande de règle (d'inclusion ou d'exclusion)

- 4-16 Paramètres d'objet de règle (à inclure ou à exclure)

- 6-1 Options DIVAnetAdmin

- 7-1 Demandes de contenu DIVArchive prises en charge

- 7-2 Méthodes de restauration DIVAnet

- 7-3 Paramètres dérivés de copie DIVAnet

- 7-4 Méthodes de copie de site à site

- 7-5 Types de suppression

- 7-6 Autres commandes DIVArchive non liées à du contenu prises en charge

- 8-1 Erreurs courantes DIVAnet

- 8-2 Erreurs courantes DIVAnetUI

Préface

Ce document décrit l'installation, la configuration et l'administration d'Oracle DIVAnet 2.1.

Remarque :
Avant DIVAnet 2.0, l'application DIVAnet était installée, révisée et mise en disponibilité avec Oracle DIVArchive. DIVAnet est désormais mise en disponibilité et révisée indépendamment de DIVArchive. DIVAnet 2.1 n'est pas directement compatible avec la version existante DIVAnet 1.0 (dans DIVArchive 6.x et 7.x), et est configurée différemment. Il ne s'agit donc pas d'une version de remplacement.

Accessibilité de la documentation

Pour plus d’informations sur l’engagement d’Oracle pour l’accessibilité à la documentation, visitez le site Web Oracle Accessibility Program, à l'adresse http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc.

Accès aux services de support Oracle

Les clients Oracle qui ont souscrit un contrat de support ont accès au support électronique via My Oracle Support. Pour plus d'informations, visitez le site http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info ou le site http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs si vous êtes malentendant.

1 Introduction

- Présentation du système

- Prise en charge d'API

- Interface utilisateur (DIVAnetUI)

- Interface de ligne de commande (DIVAnetAdmin)

- Règles d'accès

- Autres composants DIVArchive

Présentation du système

Oracle DIVAnet fournit une vue unifiée des actifs numériques archivés sur de multiples systèmes DIVArchive distribués et DIVAcloud. Il facilite le déplacement de contenu entre les sites DIVArchive et à partir des serveurs et disques source/destination du client. Il effectue ses tâches aux fins de récupération après sinistre, de distribution de contenu, de contrôle d'accès, de maintien des performances et de disponibilité des contenus.

En se connectant à plusieurs sites DIVArchive, DIVAnet crée un système d'archivage virtuel qui couvre les emplacements géographiques. Vous pouvez tirer parti des sites de récupération après sinistre pour assurer une disponibilité d'actifs supplémentaires en cas de panne et améliorer les performances d'archivage et de restauration de certains actifs quand les systèmes s'exécutent normalement. Vous pouvez utiliser les installations DIVA d'autres parties de votre organisation en tant que sites de sauvegarde stratégiques, partenaires partageant du contenu et participants dans des workflows de média d'entreprise globaux. DIVAnet facilite le suivi du contenu pouvant exister dans des sites DIVA locaux et distants ainsi que dans le cloud.

Les applications peuvent utiliser l'API DIVArchive pour se connecter directement à DIVAnet. Cela permet aux applications de stocker des actifs numériques dans différents emplacements géographiques et d'y accéder. DIVAnet synchronise les informations sur les actifs de chaque site DIVA pour présenter à tout moment un inventaire à jour. DIVAnet utilise ces informations pour appliquer l'unicité des noms et pour sélectionner le site le plus adapté pour différentes demandes (demandes de restauration et de copie notamment). DIVAnet fournit également des règles d'accès pour limiter les opérations que les utilisateurs sont autorisés à effectuer.

Prise en charge d'API

DIVAnet permet aux applications écrites à l'aide de l'API DIVA de contrôler plusieurs sites DIVArchive comme s'il s'agissait d'un seul grand système d'archivage. L'API DIVArchive permet aux applications clientes de se connecter à un système d'archivage et de stocker, copier, supprimer ou restaurer des contenus (voir la référence Oracle DIVArchive C++ API Reference Manual dans la bibliothèque Oracle DIVArchive 7.4 Additional Features Documentation pour plus d'informations sur l'API DIVArchive). Cette API prend également en charge l'extraction d'informations sur les objets archivés. DIVAnet prend en charge un sous-ensemble de l'API DIVA relativement important qui correspond à celui généralement utilisé par des applications connues telles que les applications MAM (Media Asset Management).

Pour plus d'informations, reportez-vous au Chapitre 7.

Interface utilisateur (DIVAnetUI)

DIVAnetUI est une application qui permet à l'utilisateur de surveiller des demandes DIVAnet et de consulter, copier, restaurer et supprimer des actifs DIVAnet (objets DIVA archivés) sur de multiples sites DIVArchive. Toutes les demandes de niveau DIVAnet peuvent être surveillées, qu'elles soient émises via l'API ou via l'interface utilisateur elle-même. Vous pouvez également afficher des informations sur les actifs pour tous les sites DIVArchive configurés, que l'actif ait été archivé via DIVAnet ou pas. DIVAnetUI offre une grande souplesse d'interrogation, pour les informations relatives aux demandes comme pour celles relatives aux actifs.

DIVAnet 2.1 ne prend pas en charge l'interface graphique (GUI) de contrôle de DIVArchive (même en mode Direct). Utilisez l'application DIVAnetUI pour surveiller DIVAnet et l'interface graphique (GUI) de contrôle de DIVArchive pour surveiller DIVArchive.

Pour plus d'informations, reportez-vous au Chapitre 5.

Interface de ligne de commande (DIVAnetAdmin)

L'outil de ligne de commande DIVAnetAdmin permet d'effectuer diverses tâches d'administration de DIVAnet, notamment :

- Surveillance du statut de synchronisation de la base de données

- Définition de paramètres et limites propres au site

- Affichage des connexions d'API

- Rechargement des profils de workflow et règles d'accès

- Modification du niveau de journalisation des services DIVAnet.

Pour plus d'informations, reportez-vous au Chapitre 6.

Règles d'accès

DIVAnet permet de créer des règles qui régissent quels utilisateurs et quels profils de workflow sont autorisés à effectuer des opérations données. Par exemple, vous pouvez créer des règles qui limitent quelles sources/destinations peuvent recevoir du contenu restauré ou qui limitent quels objets peuvent être copiés vers des sites.

Pour plus d'informations, reportez-vous au Chapitre 4.

Autres composants DIVArchive

Certaines tâches de transfert intersite ne sont pas spécifiquement exécutées par DIVAnet. Le service Drop Folder Monitor (DFM) surveille le contenu qui est écrit sur disque dans un dossier. Il archive ensuite ce contenu dans un système DIVArchive une fois que celui-ci a été complètement transféré. DFM peut être utilisé dans le cadre d'un workflow de copie intersite et peut également être utilisé avec DIVAnet. Pour plus d'informations sur DFM, reportez-vous au document Oracle DIVArchive Drop Folder Monitor (DFM) User's Guide dans la bibliothèque Oracle DIVArchive 7.4 Additional Features Documentation.

Vous pouvez configurer Oracle DIVArchive Storage Plan Manager (SPM) pour qu'il effectue automatiquement une opération quand du contenu arrive sur un site DIVArchive. Une de ces opérations consiste à restaurer le nouveau contenu vers un dossier de dépôt, lequel peut à son tour archiver ce contenu dans un autre système DIVA. Cela permet une sorte de réplication du contenu. Pour plus d'informations sur SPM, reportez-vous au document Oracle DIVArchive Storage Plan Manager (SPM) Guide dans la bibliothèque Oracle DIVArchive 7.4 Additional Features Documentation.

Enfin, DIVArchive permet de transférer du contenu depuis des sources/destinations vers des systèmes DIVA et inversement et de copier et supprimer du contenu archivé.

DIVArchive, SPM, DFM et DIVAnet fonctionnent à l'unisson pour satisfaire les workflows de médias distribués.

2 Planification de l'installation

DIVAnet est une application distribuée qui est généralement configurée sur plusieurs sites DIVA. Ce chapitre décrit les concepts nécessaires pour déterminer quels services DIVAnet doivent être installés et où. Il comprend trois étapes principales :

1. Vous devez comprendre quels sites doivent être connectés pour réaliser les workflows voulus pour un site spécifique. Voir Présentation de la connectivité de site.

2. Vous devez activer l'accès distant pour chaque site du système (ou l'accès local). Voir Activation des sites pour l'accès distant.

3. Vous devez configurer l'accès client local sur les sites ayant des applications client qui contacteront et utiliseront les workflows DIVAnet localement. Voir Configuration de l'accès client local.

Présentation de la connectivité de site

Un site DIVAnet est défini comme une (et une seule) installation DIVArchive (pouvant exister dans le cloud) et un ou plusieurs services DIVAnet. Un nom unique est affecté à chaque site. Chaque service DIVAnet appartient à un site particulier, indiqué par le paramètre LocalSitename dans les fichiers de configuration de DIVAnet. Vous pouvez configurer de multiples sites DIVAnet, chacun avec ou sans accès client local. Les sites DIVAnet peuvent communiquer entre eux et répliquer mutuellement leurs informations.

Le type de connectivité DIVAnet le plus élémentaire est l'utilisation de DIVAnet en tant que simple proxy DIVArchive pour un seul système DIVArchive. Dans cette configuration, le mode Direct de DIVAnet est utilisé. Vous pouvez configurer des règles d'accès pour autoriser ou rejeter des opérations sur une connexion d'API DIVA. Ce mode n'offre pas une vue fédérée de sites multiples et ne peut pas être utilisé (par exemple) pour la copie entre sites. Pour plus d'informations sur la configuration du mode Direct de DIVAnet, reportez-vous à la section Configuration des ports API client.

Pour que de multiples sites DIVA puissent être gérés comme un seul grand système d'archivage, il faut que les sites DIVAnet soient connectés ensemble à l'aide de services DIVAnet. Les sections suivantes de ce chapitre décrivent comment configurer DIVAnet pour obtenir une vue fédérée du contenu archivé.

DIVAnet peut se connecter à des sites distants pour extraire des informations sur les actifs, surveiller le statut du site distant et envoyer des demandes au site (demande de restauration, par exemple), afin de satisfaire les demandes de niveau DIVAnet. La richesse de cette interaction permet à DIVAnet de fonctionner comme un seul et même système d'archivage.

Remarque :
Certains déploiements DIVAnet ne requièrent pas que chaque site soit connecté à tous les autres dans le réseau.

L'illustration suivante présente un exemple d'un déploiement DIVAnet type comportant trois sites : New York, Los Angeles et Dallas. Dans cet exemple, les applications du site New York peuvent voir et copier des actifs depuis les sites Los Angeles et Dallas (ainsi que ceux existants dans New York). En outre, les applications du site Los Angeles peuvent voir et copier des actifs depuis les sites New York et Dallas. Aucune application n'est en cours d'exécution sur le site Dallas.

Pour réaliser ce déploiement, vous devez d'abord configurer un site pour l'accès distant. Le site Dallas est parfait pour illustrer ce scénario car il n'a pas de clients locaux à servir. Nous verrons plus loin comment Dallas est connecté à New York. Nous nous demanderons ensuite comment configurer un site pour l'accès client, en examinant les sites New York et Los Angeles et la façon dont ils sont connectés.

Services DIVAnet

Un service DIVAnet est un service Windows ou Linux installé sur un serveur qui est chargé d'exécuter des tâches informatiques dans un déploiement DIVAnet. Le Tableau 2-1 présente un récapitulatif des services DIVAnet disponibles.

Tableau 2-1 Services DIVAnet

Service

Description

Client Adapter

Le service DIVAnet ClientAdapter accepte des demandes de l'API DIVA et des clients Web, et interagit avec les sites DIVArchive et la base de données DIVAnet pour satisfaire ces demandes. Configuré lors de l'implémentation de l'accès client (application) local. Il peut également être utilisé dans un déploiement DIVAnet minimal basé sur proxy uniquement (mode Direct de DIVAnet, décrit dans la section Configuration des ports API client).

Pour plus d'informations, voir Service ClientAdapter de DIVAnet.

Manager Adapter

Le service ManagerAdapter sert de pont entre DIVAnet et Oracle DIVArchive Manager. Assure l'accès distant pour un site DIVA. Configuré pour tous les sites DIVAnet, en particulier ceux dont les informations d'actif seront synchronisées.

Pour plus d'informations, voir Service ManagerAdapter de DIVAnet.

DB Sync

Le service DbSync est responsable de la synchronisation des informations d'actif provenant de plusieurs sites DIVArchive et du stockage des informations dans la base de données DIVAnet. Configuré lors de l'implémentation de l'accès client (application) local.

Pour plus d'informations, voir Service DbSync de DIVAnet.

Activation des sites pour l'accès distant

L'activation d'un site DIVArchive pour l'accès distant par d'autres systèmes DIVAnet implique de configurer un service ManagerAdapter sur le site et de configurer DIVArchive pour l'accès distant.

L'illustration suivante présente un exemple de deux sites : le site New York avec une configuration DIVAnet complète (accès distant et accès client local) et le site Dallas configuré uniquement pour l'accès distant. Le site Dallas n'a qu'un service DIVAnet en cours d'exécution : le service ManagerAdapter. DIVArchive a été configuré afin de s'interfacer correctement avec d'autres sites.

Service ManagerAdapter de DIVAnet

Le service ManagerAdapter sert de pont entre DIVAnet et DIVArchive Manager. Il doit être configuré pour fournir l'accès distant par d'autres systèmes DIVAnet. Pour des raisons de sécurité et de performance, Oracle recommande que le service ManagerAdapter soit installé sur le même système que DIVArchive Manager. De même, il arrive souvent que le service ClientAdapter et la base de données DIVAnet s'exécutent ensemble sur un serveur entièrement différent. Le service ManagerAdapter est configuré à l'aide d'un fichier de configuration simple. Pour plus d'informations, reportez-vous au Chapitre 4.

DIVArchive

La majeure partie de la configuration nécessaire à l'exécution des workflows DIVAnet est effectuée sur chaque site DIVArchive. Cette section décrit certains concepts nécessaires pour comprendre comment DIVAnet interagit avec DIVA, ainsi que l'importance de la configuration DIVA. Pour plus de détails sur la configuration de DIVArchive, reportez-vous au Guide d'installation et de configuration d'Oracle DIVArchive.

Objets et instances

Dans un système DIVArchive, les objets archivés sont identifiés par deux paramètres : un nom d'objet (Object Name) et une catégorie d'objet (Object Category). La catégorie fait partie du nom formel de l'objet (sorte d'espace de noms). Par exemple un objet ayant le nom CLIP01 et la catégorie MOVIES est différent d'un objet ayant le nom CLIP01 et la catégorie COMMERCIALS.

DIVAnet utilise le nom et la catégorie d'objet pour associer des objets sur différents sites.

Remarque :
Si un objet existe sur deux sites distincts sous les mêmes nom et catégorie d'objet, DIVAnet considère les deux comme un seul et même objet.

Quand des actifs sont archivés à l'aide de DIVAnet, DIVAnet rejette (par défaut) les nouveaux actifs qui présentent les mêmes nom et catégorie que des actifs déjà archivés sur d'autres sites. En revanche, les archives envoyées directement à un système DIVArchive ne font pas l'objet de ce filtrage. Un archivage qui n'utilise pas DIVAnet risque de produire un objet sur le site B ayant un contenu différent de l'objet correspondant sur le site A. Cela peut ensuite amener DIVAnet à restaurer le mauvais contenu.

Dans DIVArchive, chaque objet archivé peut contenir plusieurs instances : une instance pour chaque copie physique de l'objet sur bande ou sur disque. Chaque instance est associée à un numéro d'ordre. La numérotation commence à zéro, avec un incrément de un pour chaque instance de l'objet. Ainsi, vous pouvez faire référence à une instance particulière sur un système DIVA en indiquant le nom et la catégorie de l'objet et le numéro d'ordre de l'instance.

DIVAnet affecte son propre jeu de numéros d'ordre d'instance, lesquels sont dérivés des numéros d'ordre DIVArchive. Le but est que pour chaque objet, les numéros d'ordre d'instance DIVAnet soient uniques sur l'ensemble des sites DIVAnet.

Source et destinations

Une source/destination DIVArchive contient les informations nécessaires pour communiquer avec un serveur ou disque externe à DIVArchive. Les clients transfèrent du contenu depuis et vers DIVArchive via ces serveurs et disques.

DIVAnet applique une convention importante concernant les noms de source/destination.

Remarque :
Si une source/destination sur un site a le même nom qu'une autre sur un autre site, DIVAnet estime que les deux font référence aux mêmes serveur et (ou) disque physiques.

Cette convention est importante dans la configuration d'un système DIVAnet (pour plus d'informations, voir Workflow de restauration). Si les source/destinations sont adressables via l'API et qu'elles pointent vers les mêmes serveur, disque et chemin physiques, vous devez leur donner le même nom.

Configuration des sources/destinations de transfert

Pour utiliser DIVAnet en vue de transférer des contenus d'un site vers un autre, configurez au moins une source/destination accessible à partir des deux sites. Cette source/destination commune sera utilisée par DIVAnet pour copier les objets d'un site à l'autre. Sur les deux sites, les configurations de source/destination doivent présenter les caractéristiques suivantes :

- Même nom : Sur tous les sites, vous devez configurer le même nom pour les sources/destinations qui font référence aux mêmes serveur et disque et répertoire physiques.
Les mappages de site à site de DIVAnet peuvent traiter des sources/destinations qui pointent vers un même emplacement mais qui n'ont pas nécessairement le même nom. Pour plus d'informations, voir Mappages de site à site.

- Même emplacement : Les deux entrées de source/destination doivent pointer vers le même emplacement (chemin) sur le disque d'un serveur. Les types de transfert (par exemple, FTP_STANDARD, DISK) peuvent différer sur chaque site ; ils peuvent même avoir des chemins racine différents dans la configuration. Par exemple, une source/destination nommée NY_SHOWS peut être de type DISK sur le site New York mais de type FTP sur le site Los Angeles.

- Aucun transcodage ou attribution d'un nouveau nom : Pour les sources/destinations utilisées dans des copies intersites, ne configurez pas la source/destination pour transcodage à la restauration. Cela entraînerait l'archivage de contenu incorrect sur les sites DIVA.

- Suppression sur la source : Pour chaque source/destination qui sera utilisée dans des commandes de copie, définissez l'option -allow_delete_on_source dans la configuration de source/destination DIVArchive. Le contenu sera ainsi supprimé du site après avoir été transféré vers DIVA. Vous spécifiez cette option dans le champ d'options du panneau de configuration Source/Destination de DIVA.

- AXF et checksums : Vous pouvez activer des comparaisons de checksum sur des copies intersites (opérations de copie d'un site à un autre) en activant l'option AXF Genuine Checksums dans DIVArchive. Dans l'utilitaire de configuration de DIVArchive, sélectionnez la source/destination utilisée pour les copies, puis sélectionnez l'option AXF Genuine Checksum. Vous pouvez ensuite définir l'option -axf dans le paramètre AdditionalOptions de mappage de site à site DIVAnet. Les informations de checksum seront ainsi intégrées dans le wrapper AXF sur le site source, puis vérifiées à nouveau sur le site cible.

Ne prêtez pas attention au paramètre Site figurant dans le panneau Source/Destination de l'utilitaire de configuration de DIVArchive. Le nom de site indiqué ici n'est utilisé que par DIVA et ne correspond pas à un site DIVAnet (voir le Guide d'installation et de configuration d'Oracle DIVArchive pour plus d'informations).

Attention :
La modification des noms des paramètres de configuration DIVArchive (tels que Source/Destinations, Media Names et Storage Plans) lors de la connexion à DIVAnet peut provoquer des erreurs.

Média (de stockage) et plans de stockage

Quand DIVAnet copie des objets d'un système DIVA à un autre, il faut faire attention à bien affecter le nom du média (Media Name) et le nom du plan de stockage (Storage Plan Name) de la copie sur le site cible. Utilisez une stratégie de dénomination appropriée pour les valeurs de média sur chaque système DIVA.

DIVAnet enregistre les noms des médias DIVA quand il synchronise les instances d'objet. Vous pouvez configurer DIVAnet pour affecter automatiquement le média/plan de stockage sur une opération de copie (pour plus d'informations, voir Sélection par DIVAnet (média avec la valeur any)). Un des moyens de configurer cette fonctionnalité consiste à effectuer l'archivage vers le site cible avec le même nom de plan de stockage que l'objet source. Pour que cela fonctionne, les plans de stockage appropriés doivent être configurés dans le site DIVA cible. Vous pouvez également utiliser les mappages de médias DIVA pour convertir le nom du plan de stockage en un média ou un autre plan de stockage, le tout dans le site DIVA cible.

Drop Folder Monitor (DFM)

DFM surveille l'arrivée du nouveau contenu dans les dossiers, puis archive le nouveau contenu dans DIVArchive. En effectuant la restauration vers un dossier de dépôt donné, DFM peut sélectionner le contenu et l'archiver vers un autre système DIVA.

DIVAnet peut mettre en oeuvre des workflows de copie sans DFM, mais dans certains cas, il est nécessaire, voire souhaitable de l'utiliser. Pour effectuer des copies sans DFM, vous pouvez utiliser la méthode de transfert RestoreAndArchive de DIVAnet. Toutefois, il existe des cas où il est préférable d'utiliser DFM. Par exemple, dans le cas de sites autonomes voulant effectuer leurs propres nettoyages de contenu suite à un échec de transfert ou dans le cas où des systèmes dans lesquels des accélérateurs WAN sont utilisés. Pour utiliser DFM pour des transferts, utilisez la méthode de transfert de site à site RestoreAndMonitor de DIVAnet. Pour plus d'informations, voir Mappages de transfert site à site (profil de workflow).

Configuration de l'accès client local

La configuration de l'accès client local implique la configuration :

- du DIVArchive local pour l'accès distant (voir Activation des sites pour l'accès distant),

- du service ClientAdapter,

- d'un service DbSync,

- d'une base de données DIVAnet.

La configuration de tous les services DIVAnet active le site pour un traitement de workflow DIVAnet complet.

Dans l'illustration suivante, les sites New York et Los Angeles sont configurés pour un traitement de workflow DIVAnet complet. Les applications dans le site Los Angeles se connectent directement au service ClientAdapter dans LA. Ce faisant, elles peuvent extraire du contenu de New York, si nécessaire. La base de données DIVAnet locale fournit une vue globale des actifs sur l'ensemble des sites, même en cas de perte de connectivité entre un site et un autre. S'ils disposent des autorisations nécessaires, les utilisateurs de DIVAnetUI du site LA peuvent copier du contenu du site New York vers le site LA, et même supprimer du contenu du site New York.

Bien qu'il soit techniquement possible de configurer Customer App 2 pour une connexion distante au service ClientAdapter de New York, cette configuration offre souvent de meilleurs résultats en termes de disponibilité, de sécurité et d'audit. En outre, la performance et l'évolutivité sont souvent renforcées, en particulier dans le cas de liaisons WAN lentes ou peu fiables.

Service ClientAdapter de DIVAnet

Les clients d'application qui veulent utiliser l'API DIVA ou l'interface graphique DIVAnet, se connectent au service ClientAdapter de DIVAnet. Ce service DIVAnet accepte les connexions Web et de socket des applications et traite les demandes. Un service ClientAdapter est configuré sur chaque site ayant des applications qui sont locales pour le site où DIVArchive et DIVAnet sont installés. Le service ClientAdapter communique avec les sites locaux et distants via le service ManagerAdapter. Il peut également se connecter directement aux DIVArchive Managers en mode Socket.

Le service ClientAdapter est configuré à l'aide d'un (ou de deux) fichiers de configuration (pour plus d'informations, reportez-vous au Chapitre 4).

Service DbSync de DIVAnet

Le service DbSync est responsable de la synchronisation des informations d'actif provenant de plusieurs sites DIVArchive et du stockage des informations dans la base de données DIVAnet. DbSync communique à distance avec les services ManagerAdapter sur des sites multiples pour synchroniser des informations d'objet archivé. Le service DbSync est généralement déployé avec le service ClientAdapter. Le service DbSync et le service ClientAdapter requièrent tous les deux un accès direct à la base de données DIVAnet.

Le service DbSync est configuré à l'aide d'un seul fichier de configuration (pour plus d'informations, reportez-vous au Chapitre 4).

Sites en lecture seule

Vous pouvez configurer un site en lecture seule, ce qui signifie que les informations d'actif de ce site seront synchronisées, mais qu'aucune demande (ni aucun autre message) ne sera envoyé au site. Vous configurez le site (par exemple, le site diva4) dans le fichier de configuration DbSync mais pas dans la configuration ClientAdapter. Le site diva4 sera effectivement en lecture seule. Les informations d'actif de ce site seront interrogeables dans l'interface utilisateur et dans des appels d'API d'information, mais les demandes envoyées au site (à l'aide de DIVAnet) seront rejetées.

Base de données DIVAnet

La configuration de l'accès client local DIVAnet implique également la configuration d'une base de données DIVAnet.

Nettoyage d'objet

DIVAnet satisfait parfois une opération de restauration en copiant temporairement un objet d'un site distant sur le site local avant de le restaurer. Ainsi, les restaurations futures de contenu seront beaucoup plus rapides. DIVAnet ne supprime pas automatiquement l'instance de disque après la restauration. A la place, il laisse le contenu au cas où d'autres voudraient le restaurer.

DIVArchive comporte deux outils qui peuvent automatiquement nettoyer du contenu quand un disque/une baie donné devient plein :

- Oracle DIVArchive Storage Plan Manager (SPM) offre une fonctionnalité permettant de nettoyer automatiquement les instances de disque pour un site DIVA particulier.

- DIVArchive Local Delete peut assurer une fonction similaire, mais aussi (facultativement) vérifier si un objet existe déjà sur d'autres sites DIVA.

Comme DIVArchive est configuré pour créer une instance de disque de proximité par défaut, le nettoyage d'objet devra probablement se faire sur un site DIVA configuré uniquement pour l'accès DIVAnet à distance.

Compatibilité des versions de DIVAnet

DIVAnet 2.1 est compatible avec DIVArchive 7.3.1 et les versions ultérieures. Certaines fonctionnalités introduites dans des versions supérieures de DIVArchive risquent de n'être accessibles à DIVAnet qu'après une nouvelle mise à niveau.

Les services ClientAdapter et DbSync de DIVAnet 2.1 sont compatibles avec le service ManagerAdapter de DIVAnet 2.0, à une exception près. Le mode Proxy de DIVAnet (mode Direct sans base de données DIVAnet) ne peut pas se connecter à DIVAnet 2.0 ManagerAdapter.

3 Installation de DIVAnet

- Tâches préalables à l'installation

- Installation du logiciel DIVAnet

- Création de la base de données DIVAnet

- Création des fichiers de configuration DIVAnet

- Installation et démarrage des services DIVAnet

- Affichage des journaux

- Vérification de la configuration

- Synchronisation de la base de données DIVAnet

- Mise à niveau de DIVAnet

Tâches préalables à l'installation

- DIVAnet est une application distribuée, ce qui signifie qu'elle est souvent installée sur plusieurs systèmes. Reportez-vous au Chapitre 2 pour savoir sur quels systèmes et serveurs l'application DIVAnet peut être installée et quels services DIVAnet spécifiques doivent être installés.

- Chaque site DIVArchive connecté à DIVAnet doit exécuter DIVArchive 7.3.1 ou une version supérieure.

- DIVAnet peut être installé sur des plates-formes Windows 64 bits ou des plates-formes Linux 64 bits (Oracle Linux version 7 ou supérieure). DIVAnet peut être installé dans le même répertoire de base que DIVArchive ou dans un répertoire distinct.

- Sur les ordinateurs exécutant Windows, le programme d'installation de DIVAnet nécessite des privilèges d'administrateur. Sur les ordinateurs exécutant Linux, le programme d'installation de DIVAnet nécessite un compte utilisateur nommé diva.

- Par défaut, le programme d'installation de DIVAnet gère l'installation des services DIVAnet, de l'interface utilisateur DIVAnet et d'un environnement d'exécution Java (JRE) compatible Java 8 64 bits. DIVAnet utilise le JRE installé pour l'exécution. L'installation de la base de données DIVAnet nécessite l'installation directe sur le système DIVAnet des logiciels suivants : Oracle Database 11g version 2 (ou supérieure) et Oracle SQLPlus (à partir de la version Oracle 11).

- Pour une réinstallation de DIVAnet, assurez-vous que les composants DIVAnet ne sont pas en cours d'exécution.

Installation du logiciel DIVAnet

Le logiciel DIVAnet peut être installé sur les systèmes d'exploitation Windows et Linux (Oracle Linux 7 ou version supérieure). La procédure d'installation sur chaque plate-forme est décrite dans les sections suivantes.

Installation de DIVAnet sur Windows

Procédez de la manière suivante pour installer DIVAnet dans un environnement Windows :

1. Lancez l'exécutable d'installation de DIVAnet, DIVAnet_V2.1.version.exe, sous un compte disposant de privilèges d'administrateur.

2. Sélectionnez les composants voulus et cliquez sur Next.

- Sélectionnez Java si vous ne l'avez pas précédemment installé dans le répertoire cible.

- Si vous voulez uniquement installer l'interface utilisateur de DIVAnet, désélectionnez DIVAnet Services.

3. Indiquez un répertoire d'installation cible. Ce sera le répertoire de base de DIVAnet. Cliquez ensuite sur Install.

Remarque :
Vous pouvez utiliser le répertoire d'installation de DIVArchive comme répertoire de base pour DIVAnet. Cependant, Oracle recommande d'installer DIVAnet dans un répertoire qui lui est propre.

Installation de DIVANET sur Oracle Linux

Si vous utilisez le système d'exploitation Linux, vous devez créer un utilisateur nommé diva et un utilisateur nommé divanetsvc. L'utilisateur divanetsvc doit avoir des droits d'écriture, de lecture et d'exécution sur les fichiers appartenant à diva. L'utilisateur diva doit bénéficier des privilèges sudo pour la commande Linux systemctl. Vous devez exécuter l'installation en tant qu'utilisateur diva, admin ou root. Vous devez créer l'utilisateur diva avant d'installer le logiciel. Le programme d'installation comprend une option qui permet de créer les utilisateurs diva et divanetsvc avant de lancer l'installation.

Procédez de la manière suivante pour installer DIVAnet dans un environnement Linux :

1. Ouvrez une session de terminal et accédez au répertoire parent de la version souhaitée de DIVAnet.

2. Placez dans ce répertoire le package d'installation de DIVAnet (par exemple, DIVAnet-2.1-RELEASE.sh). Le programme d'installation permet d'installer DIVAnet dans un sous-répertoire enfant de ce répertoire parent.

3. Lancez l'installation de DIVAnet à l'aide de la commande suivante :
sh ./DIVAnet-2.1-RELEASE.sh

4. Le programme d'installation comprend une option qui permet de créer les utilisateurs Linux requis diva et divanetsvc avant d'installer le logiciel. Une fois que ces utilisateurs sont installés, avec les autorisations correctes, sélectionnez l'option qui lance l'installation du logiciel DIVAnet.

5. Une invite vous demandera le nom du sous-répertoire où DIVAnet doit être installé. Appuyez sur Entrée pour utiliser le sous-répertoire par défaut, nommé DIVAnet, ou bien indiquez un nom de sous-répertoire personnel. Appuyez ensuite sur Entrée pour créer le répertoire d'installation.
Le processus d'installation de DIVAnet commence alors, et tous les fichiers et dossiers concernés sont transférés vers le répertoire cible indiqué.

Les sections suivantes décrivent les éventuelles étapes à effectuer pour terminer l'installation. Pour plus d'informations, reportez-vous au Chapitre 2.

Création de la base de données DIVAnet

Pour créer la base de données DIVAnet, vous devez d'abord créer les tables DIVAnet puis configurer les sites DIVArchive.

Création des tables

Cette étape consiste à créer les tables de la base de données DIVAnet qui résideront sur un serveur Oracle en cours d'exécution. Cette étape n'est requise que pour une installation DIVAnet complète (voir le Chapitre 2).

Création du schéma de base de données DIVAnet

Pour exécuter les scripts de création SQL, vous devez avoir SQLPlus (logiciel client Oracle 11g ou version ultérieure) sur le système où vous installez DIVAnet. Vérifiez que le chemin d'accès à l'utilitaire sqlplus figure dans la variable d'environnement PATH de votre système.

1. Ouvrez une fenêtre de ligne de commande ou un terminal d'exécution de commandes. Accédez au répertoire de base DIVAnet (où DIVAnet est installé).

2. Passez dans le répertoire Program/Database/divanet/Install.

3. Exécutez la commande suivante :
Windows :

create_divanet_user.bat {syspassword} {username} {userpassword} {oracle_tns_name}

Linux :

create_divanet_user.sh {syspassword} {username} {userpassword} {oracle_tns_name}

Dans la commande précédente, syspassword est le mot de passe du système Oracle, username est le nom d'utilisateur/de schéma Oracle qui contiendra les tables DIVAnet et oracle_tns_name est le nom TNS Oracle pour la base de données DIVAnet que vous voulez utiliser pour l'installation. S'il n'y a pas de nom TNS défini pour la base de données, vous pouvez vous reporter à la section suivante pour créer un nom TNS en temps réel.

Suppression du schéma de base de données DIVAnet

Pour supprimer le schéma de base de données DIVAnet, procédez comme suit.

Attention :
Cette action va supprimer toutes les données de la base de données DIVAnet.

1. Passez dans le répertoire Program/Database/divanet/Install.

2. Exécutez la commande suivante :
Windows :

delete_divanet_user.bat syspassword username oracle_conn_string

Linux :

delete_divanet_user.sh syspassword username oracle_conn_string

Dans la commande précédente, syspassword est le mot de passe du système Oracle, username est le nom d'utilisateur ou le nom de schéma qui contiendra les tables DIVAnet et oracle_conn_string est soit le nom TNS de la base de données DIVAnet à utiliser, soit la chaîne de connexion Oracle (voir la section suivante) pour l'installation. S'il n'y a pas de nom TNS défini pour la base de données, reportez-vous à la section suivante pour créer une chaîne de connexion Oracle à utiliser dans les scripts d'ajout et de suppression.

Chaîne de connexion Oracle

S'il n'y a pas de nom TNS défini pour la base de données, vous pouvez indiquer une chaîne de connexion Oracle. Le format de cette chaîne est le suivant :

netaddress:port/remote_servicename

Où :

- netaddress est l'adresse réseau où s'exécute la base de données.

- port est le port où les clients peuvent se connecter.

- remote_servicename est le nom du service Oracle distant. Il est différent du nom de service utilisé localement. La valeur par défaut pour le package d'installation de la base de données DIVA Oracle est lib5.world. Exemple de chaîne de connexion complète : 183.34.34.67:1521/lib5.world.

Ajout de sites

Une fois les tables DIVAnet créées, vous devez configurer les sites DIVA dans la base de données DIVAnet. Pour configurer les sites de la base de données, exécutez le script addSites comme suit :

1. Accédez au répertoire de base DIVAnet, puis au sous-dossier Program/divanet/bin.

2. Exécutez le script addSites :
Windows : addSites.bat

Linux : addSites.sh

Ce script vous guide pour ajouter des enregistrements de nom de site et pour configurer des noms de site, des emplacements et des commentaires. Les connexions réseau aux sites sont configurées dans le fichier de configuration ClientAdapter (voir le Chapitre 4). Vous devez créer des noms de site faciles à lire qui reflètent l'emplacement physique ou la fonction du site.

Remarque :
Les noms de site que vous indiquez dans cette étape seront utilisés lors de la configuration des services DIVAnet locaux et distants. Assurez-vous de la cohérence et de la validité des noms de site avant d'exécuter le script addSites. Si vous faites une erreur en exécutant la commande, vous pouvez supprimer le site logiquement dans le script addSites. Une fois les noms de site définis dans la base de données, vous pouvez poursuivre l'installation de DIVAnet.

Création des fichiers de configuration DIVAnet

Reportez-vous au Chapitre 2 pour déterminer quels services DIVAnet doivent être configurés, puis au Chapitre 4 pour obtenir des détails sur la configuration de chaque service.

Sous le répertoire de base DIVAnet, dans le sous-répertoire Program/conf/divanet/templates, vous trouverez des modèles de fichier de configuration pour chaque service DIVAnet à configurer. Chaque modèle de fichier comporte une extension .ini. Vous devez copier chaque fichier dans le répertoire parent (en l'occurrence, Program/conf/divanet). Lors de la copie, veillez à supprimer l'extension .ini.

Au début de chaque fichier .ini figure la documentation des paramètres disponibles. Pour chaque site DIVAnet, configurez un fichier ManagerAdapterConfig.xml. Pour une installation DIVAnet complète, vous configurez également les fichiers ClientAdapterConfig.xml et DBSyncConfig.xml.

Vous pouvez conserver la valeur par défaut de nombreux paramètres. Vous ne devriez pas avoir à modifier les fichiers de configuration figurant dans le dossier Program/conf/divanet/wrapper. Vous pouvez éventuellement ajouter des informations au fichier divaEnv.conf (voir Ajout de variables de script à un fichier de configuration pour plus d'informations).

Remarque :
Si vous hésitez quant aux paramètres à modifier après avoir lu cette documentation, contactez le support technique Oracle.

Installation et démarrage des services DIVAnet

Reportez-vous au Chapitre 2 pour déterminer quels services doivent être installés et configurés.

Une fois les fichiers de configuration définis correctement, installez et démarrez les services DIVAnet. Procédez comme suit pour chaque service à installer sur chaque site DIVAnet.

Installation des services DIVAnet pour Windows

Procédez de la manière suivante pour installer les services DIVAnet dans un environnement Windows :

1. Accédez au répertoire de base DIVAnet (où DIVAnet est installé).

2. Accédez au dossier Program/divanet/bin.

3. Exécutez le script InstallDivanetService.bat, en indiquant le fichier de configuration de wrapper pour le service à installer. Par exemple, pour installer le service ManagerAdapter (obligatoire sur tous les sites où un Manager à connecter à DIVAnet s'exécute), lancez la commande suivante :

InstallDivanetService.bat ../../conf/divanet/wrapper/ManagerAdapterWrapper.conf

- Pour le service ClientAdapter, utilisez la même commande et le même chemin, mais remplacez le nom de fichier par ClientAdapterWrapper.conf.

- Pour le service DbSync, utilisez le nom de fichier DBSyncWrapper.conf.

4. Dans la fenêtre des services Windows, vous devez voir un ou plusieurs des services DIVAnet suivants :

- Divanet ManagerAdapter

- Divanet ClientAdapter

- Divanet DbSync

Les services peuvent être démarrés dans n'importe quel ordre, mais gardez à l'esprit qu'une fois le service DbSync et les services ManagerAdapter démarrés, le processus de synchronisation de la base de données démarrera automatiquement. Démarrez le service ClientAdapter pour permettre les nouvelles connexions DIVAnet et le traitement d'API.

Installation des services DIVAnet pour Linux

Procédez de la manière suivante pour installer les services DIVAnet dans un environnement Linux :

1. Ouvrez une session de terminal et accédez au répertoire Program/divanet/bin.

2. Exécutez le script divanetservice pour installer le service désiré (DbSync, ClientAdapter ou ManagerAdapter). Par exemple, pour installer le service ClientAdapter, entrez la commande suivante :
./divanetservice install ClientAdapter

Gestion des services DIVAnet sur Linux

Après avoir créé les services DIVAnet sur Linux, vous pouvez les gérer à l'aide des commandes suivantes :

Tableau 3-1 Services DIVAnet sur Linux

Opération

Commande

Liste de tous les services

./divanetservice list

Démarrer un service

./divanetservice start service_name

Arrêter un service

./divanetservice stop service_name

Redémarrer un service

./divanetservice restart service_name

Installer un service

./divanetservice install service_name

Désinstaller un service

./divanetservice uninstall service_name

Le paramètre service_name peut être DbSync, ClientAdapter ou ManagerAdapter. Il est également possible de gérer les services DIVAnet en utilisant la syntaxe de commande systemctl standard de Linux V. Vous pouvez entrer man systemctl à l'invite de commande de Linux pour obtenir des informations plus détaillées sur la commande systemctl.

Affichage des journaux

Les applications DIVAnet produisent deux types de journaux :

- Journaux de suivi : situés dans le répertoire de base DIVAnet, dans le sous-dossier Program/log/divanet. Chacun des services DIVAnet (ManagerAdapter, DbSync et ClientAdapter) crée son propre sous-dossier sous le dossier Program/log/divanet et génère ses fichiers journaux dans ce sous-répertoire.

- Journaux de service de wrapper : à examiner en priorité pour vérifier que les applications démarrent correctement. Ces journaux figurent dans le répertoire de base DIVAnet, dans le sous-dossier Program/log/divanet. Ils seront nommés de la même façon que le fichier Wrapper.conf mais avec une extension de nom de fichier .log (par exemple : ManagerAdapterWrapper.log).

Vérification de la configuration

Les erreurs les plus courantes dans la configuration de DIVAnet concernent la spécification des noms de site. Tous les sites DIVA dans le réseau DIVAnet doivent utiliser le même jeu de noms de site. Les noms de site doivent être cohérents dans tous les fichiers de configuration, ainsi que dans la base de données DIVAnet. Le paramètre LocalSitename doit être configuré correctement dans tous les fichiers de configuration.

Vous devez également vérifier la source/destination DIVArchive. Par exemple, par défaut, si le site diva1 a une source/destination qui a le même nom qu'une source/destination sur le site diva2, DIVAnet considère que les deux pointent vers la même source/destination logique. Si le même nom de source/destination est configuré sur deux sites DIVArchive différents, DIVAnet suppose que ces sources/destinations font référence au même emplacement.

Synchronisation de la base de données DIVAnet

Quand le service DbSync est démarré, il tente de synchroniser les informations d'objets archivés en consultant le service ManagerAdapter. A son tour, le service ManagerAdapter extrait les informations sur les actifs à partir du site DIVArchive auquel il est connecté. Par conséquent, vous devez démarrer le service DbSync et les services ManagerAdapter uniquement quand vous êtes prêt à lancer la synchronisation.

Remarque :
Si vous arrêtez le service DbSync, la synchronisation reprendra là où elle a été abandonnée au redémarrage du service.

L'outil de ligne de commande DivanetAdmin surveille le statut de la synchronisation de la base de données, site par site. Si DIVAnet effectue une synchronisation initiale d'un site donné, il affiche le pourcentage d'avancement de cette opération de synchronisation initiale. Si le site est à jour, DivanetAdmin indique qu'il est en état In Sync.

DivanetAdmin peut également être utilisé pour resynchroniser un site. Cela implique la suppression de tous les enregistrements d'objets archivés préalablement synchronisés à partir du site et leur resynchronisation depuis la source. Cette opération doit être utilisée à titre exceptionnel, notamment quand la base de données DIVA source a été accidentellement restaurée à partir d'une sauvegarde périmée.

Mise à niveau de DIVAnet

Il est recommandé de sauvegarder le répertoire de base DIVAnet existant avant de tenter une mise à niveau vers une nouvelle version de DIVAnet. Vous devez également arrêter tous les services DIVAnet ou programmes sur le serveur avant de procéder à une mise à niveau. Procédez de la manière suivante pour mettre à niveau le logiciel DIVAnet :

1. Suivez les instructions fournies dans la section Installation du logiciel DIVAnet. Vous installerez ainsi le dernier logiciel DIVAnet dans le répertoire de base DIVAnet.

2. Si vous mettez à niveau un système contenant une base de données DIVAnet, vous devez exécuter l'utilitaire de mise à niveau de la base. Pour cela, passez dans le répertoire Program/divanet/bin et entrez la commande suivante :
Windows : upgradeDB.bat

Linux : ./upgradeDB.sh

Le script vous demande de fournir des informations concernant la base de données DIVAnet (notamment le nom d'utilisateur de base de données et l'adresse réseau où la base réside). L'utilitaire ajoutera ou modifiera les objets de base de données requis. Le script renvoie simplement un message de succès si la base de données a déjà été mise à niveau vers la plus récente version.

4 Configuration des services DIVAnet

Avant de configurer les services DIVAnet, reportez-vous au Chapitre 2 pour une description des services DIVAnet et de leur interaction avec DIVArchive et entre eux.

- Configuration du service ClientAdapter

- Configuration du service ManagerAdapter

- Configuration du service DbSync

- Configuration des règles d'accès

- Ajout de variables de script à un fichier de configuration

Configuration du service ClientAdapter

La configuration du service ClientAdapter implique la configuration du mode de connexion des clients à DIVAnet. Elle concerne également la configuration du mode de connexion de DIVAnet à DIVArchive.

Configuration du nom de site de DIVArchive

Un site DIVAnet est défini comme un système DIVArchive et un ou plusieurs services DIVAnet (ManagerAdapter, ClientAdapter, DbSync). Un nom unique est affecté à chaque site. Les noms de site doivent être configurés dans la base de données DIVAnet (à l'aide de l'utilitaire addSites) avant la configuration de ClientAdapter. Vous devez créer des noms de site faciles à lire qui reflètent l'emplacement physique ou la fonction du site. Ces noms de site seront utilisés sur chaque site.

Remarque :
Les noms de site tiennent compte de la casse.

Configuration des ports API client

DIVAnet permet la configuration des ports de socket que les applications API client utilisent pour se connecter à DIVAnet. Le service ClientAdapter permet de configurer plusieurs ports API. Chaque port API est configuré à l'aide d'un des deux modes : Direct ou MultiDiva. Un profil de workflow peut être affecté à chaque port.

- Mode Direct : Dans ce mode, une connexion API entrante est routée directement vers un système DIVArchive sans autre traitement. Le site particulier vers lequel DIVAnet effectue le routage est configuré dans le ClientAdapter sur une base par port. Cette fonctionnalité permet à des clients locaux de se connecter à un système DIVArchive distant comme s'il était local. Le site DIVA vers lequel les messages sont routés doit être configuré dans la section DivaManagers du fichier de configuration de ClientAdapter. Notez également qu'un site peut être désigné comme opérationnel en mode Direct uniquement (pour plus d'informations, voir Configuration du nom de site de DIVArchive).
Les demandes en mode Direct ne seront pas affichées dans DIVAnetUI et elles peuvent uniquement être surveillées sur le site DIVA où elles sont routées.

Certains workflows DIVAnet ne requièrent pas de base de données DIVAnet, d'interface utilisateur DIVAnet ou de traitement en mode MultiDiva. Pour configurer un service ClientAdapter pour le mode Direct uniquement, assurez-vous que seuls des ports en mode Direct sont définis et qu'aucun WebServicePort n'est défini. Cela désactive l'utilisation de l'interface utilisateur DIVAnet. Vous trouverez un exemple de configuration dans le fichier suivant :

Program/conf/divanet/templates/ClientAdapterConfig.xml.ProxyOnly.ini

- Mode MultiDiva : DIVAnet fait apparaître tous les sites DIVA sous la forme d'un seul grand système d'archivage. Dans ce mode, une demande API entrante est routée directement vers DIVAnet. DIVAnet satisfait la demande de haut niveau en consultant d'autres systèmes DIVArchive, le cas échéant. Cette fonctionnalité permet (par exemple) la copie de contenu d'un site vers un autre, la restauration de contenu sans connaissance du site qui le contient et de nouvelles tentatives sur d'autres sites quand le contenu du premier site est inaccessible. En outre, elle offre une vue globale du contenu de tous les sites.
La progression d'une demande exécutée en mode MultiDiva peut être surveillée dans l'interface utilisateur de DIVAnet. DIVAnet crée ses propres événements au niveau demande pour informer l'utilisateur sur :

- le mode de traitement de la demande par DIVAnet,

- les demandes qui sont effectuées sur les sites DIVA,

- Les erreurs ou avertissements éventuels détectés lors des opérations.

Configuration des connexions Web client

L'application DIVAnetUI et l'outil DivanetAdmin assurent les connexions Web au service ClientAdapter. Vous pouvez configurer le port disponible pour ces connexions dans le fichier de configuration de ClientAdapter.

Configuration des profils de workflow

Un profil de workflow est un ensemble de paramètres qui définit comment les demandes entrantes seront traitées par DIVAnet. Les profils de workflow permettent de regrouper logiquement les utilisateurs et systèmes qui utilisent DIVAnet de manière similaire.

DIVAnet permet la création d'un ou de plusieurs profils dans le service ClientAdapter. Ces profils contiennent des paramètres qui sont requis par un ensemble particulier d'utilisateurs ou d'applications. Les profils de workflow sont affectés selon l'emplacement de réception de la demande (port de réception, voir la section suivante).

Dans le profil de workflow, vous pouvez personnaliser des informations telles que la liste des messages valides acceptés, les paramètres de renouvellement de tentative, les méthodes de copie de site à site ainsi que d'autres attributs.

Profils et ports API

Dans la section des ports API, un nom de profil de workflow peut être affecté à chaque port défini. Les demandes reçues sur le port API sont traitées à l'aide du profil de workflow affecté. Si aucun nom n'est défini, le profil par défaut (default) est utilisé. Les ports en mode MultiDiva peuvent avoir des noms de profil de workflow qui font référence à une section de corps de profil de workflow située plus bas dans la configuration de ClientAdapter.

Si le port est en mode Direct, le nom du profil de workflow est un libellé uniquement ; il n'y a pas de corps de profil de workflow pour les connexions en mode Direct. Toutefois, ce nom peut s'avérer utile dans les règles d'accès (voir la section suivante).

En mode MultiDiva comme en mode Direct, en l'absence de nom, la connexion utilise le profil de workflow nommé default. Chaque section de corps de profil de workflow est configurée dans le fichier ClientAdapterConfig.xml. Les sections suivantes répertorient les types d'informations configurables dans chaque profil de workflow.

Nouvelles tentatives et expirations de délai

Certaines commandes dans DIVAnet peuvent faire l'objet de nouvelles tentatives (par exemple Restore, Copy et Delete). Les paramètres pour les nouvelles tentatives, notamment la durée et l'intervalle entre chacune, sont configurables ici. Beaucoup de commandes ont leurs propres paramètres pour les nouvelles tentatives (par exemple, ceux de la commande Copy sont totalement différents de ceux de la commande Delete). Les délais d'expiration des messages et les limites de connexion peuvent également être configurés dans le profil de workflow. Les paramètres de nouvelles tentatives et d'expiration sont spécifiques du profil de workflow dans lequel ils sont définis.

Messages valides

Dans chaque profil de workflow, une liste de messages est configurée. Elle représente les messages API valides qui peuvent être acceptés par le profil de workflow considéré. Par exemple, si le message Archive ne figure pas dans la liste, les messages d'archivage ne peuvent pas être envoyés à DIVAnet via l'API (au moins pour ce profil de workflow).

Mappages de site à site

DIVAnet offre un moyen flexible de configurer le mode d'exécution des transferts de site à site. Dans chaque profil de workflow, vous configurez des paramètres de mappage pour chaque chemin de transfert (un chemin pour les transferts du site A au site B, un autre pour les transferts du site A au site C, etc.). Ce tableau est consulté quand des commandes Copy, Restore ou Partial File Restore sont reçues.

Il est utile de définir des mappages de site à site dans le profil de workflow default car d'autres profils de workflow peuvent charger leurs mappages à partir de ce profil par défaut. Cela permet de réduire le nombre de mappages dans la configuration.

Paramètres : DIVAnet prend en charge plusieurs types de transfert. La section Méthodes de transfert de site à site décrit les différents types. RestoreAndArchive est le type de transfert par défaut. RestoreAndMonitor requiert Drop Folder Monitor (DFM) ou une autre application exécutant une fonction similaire. D'autres paramètres incluent :

- Source/destination : emplacement de stockage commun pour le transfert (accessible à la fois par les sites source et cible).

- Default Media : média par défaut à utiliser lors de l'archivage sur le site cible. Le média par défaut peut être utilisé lorsqu'une copie temporaire a été initiée (par une opération de restauration, par exemple) ou quand un utilisateur a lancé une copie et indiqué que DIVAnet doit sélectionner le média.

- Options : paramètres à utiliser dans les demandes de restauration, d'archivage et de transfert.

- FilePathRoot : répertoire parent pour le stockage du contenu.

Directory Location : DIVAnet crée pour stocker les fichiers un chemin de répertoire relatif à la source/destination choisie. Ce chemin relatif est de la forme suivante :

{FilePathRoot} / {Media} / {UniqueDirName} /

Le paramètre FilePathRoot est spécifié dans les mappages de site à site. Le média n'est intégré au chemin que si l'option AppendMediaToPath est définie sur true dans les mappages (la valeur par défaut est false). Enfin, DIVAnet génère un nom de répertoire unique qui est inclus dans le chemin. Ce nom unique comprend au début le nom du site qui a lancé la demande.

Rechargement des profils de workflow

Il est possible de modifier et de recharger les paramètres spécifiés dans le profil de workflow sans redémarrer le service ClientAdapter. Le redémarrage du service ClientAdapter doit être évité car il arrête toutes les demandes en cours d'exécution et ferme toutes les connexions client. Le rechargement peut être effectué dans l'outil DivanetAdmin (pour plus d'informations sur DivanetAdmin, reportez-vous aux sections ci-après).

Remarque :
Le rechargement met à jour tous les profils de workflow, mais aussi toutes les règles d'accès.

Modification du fichier de configuration de ClientAdapter

Les tableaux suivants décrivent les paramètres pouvant figurer dans un fichier de configuration de ClientAdapter. Le fichier se présente au format XML. La colonne de valeur par défaut indique la valeur que le paramètre aura s'il n'est pas spécifié dans le fichier de configuration. Elle indique également si le paramètre est obligatoire ou facultatif.

Pour créer un nouveau fichier de configuration :

1. Accédez au répertoire de base DIVAnet (où DIVAnet est installé).

2. Accédez au dossier Program/conf/divanet/templates.

3. Copiez le fichier ClientAdapterConfig.xml.ini dans le répertoire parent, sans l'extension .ini (../ClientAdapterConfig.xml).

4. En utilisant les tableaux ci-dessous comme référence, modifiez les paramètres dans le fichier ClientAdapterConfig.xml pour configurer le service ClientAdapter.

Reportez-vous à l'Annexe A pour examiner un exemple de fichier de configuration de ClientAdapter.

Paramètres de niveau supérieur

Tableau 4-1 Paramètres de niveau supérieur de ClientAdapter

Paramètre

Description

Valeur par défaut

LocalSitename

Nom de site du site DIVAnet local.

Aucune (obligatoire)

LogDirectory

Dossier dans lequel les fichiers journaux seront générés.

Répertoire log/divanet/ClientAdapter

LogLevel

Niveau de détail auquel la journalisation du fichier de suivi intervient (ERROR, WARN, INFO, DEBUG, TRACE).

INFO

SyncTimeoutSecs

Nombre de secondes d'attente pour qu'un objet soit synchronisé.

60

WorkerThreads

Nombre de threads actifs dans les pools de threads DIVAnet. Utilisé pour le réglage des configurations de grande envergure. Dans le doute, ne définissez pas cette valeur.

25

AbortAllOnStartup

Arrêter toutes les demandes DIVAnet incomplètes au démarrage de DIVAnet, même si la demande est terminée au niveau DIVArchive. Les nouvelles demandes ne sont pas affectées.

false

MaxClientConnections

Nombre total maximal de connexions API autorisées.

200

GlobalDivanetRequestLimit

Nombre maximal de demandes DIVAnet en attente ou en cours d'exécution pouvant être acceptées dans le système. Quand la limite est atteinte, DIVAnet commence à rejeter les nouvelles demandes.

5000

InternalPollingRateMillis

Fréquence à laquelle les sites sont interrogés. Ne modifiez ce paramètre qu'en cas de lenteur de réseaux et/ou de système.

4000

WebServicePort

Port utilisé pour l'envoi de messages de gestion au service ClientAdapter.

Aucune (facultatif)

SSLWebServicePort

True si SSL doit être utilisé pour les demandes de service Web.

true

WebDefaultWorkflowProfile

Profil de workflow à utiliser pour les demandes Web (notamment DivanetUI).

Le profil default

AccessRulesFilename

Nom du fichier des règles d'accès. Ce nom de fichier est lié au répertoire dans lequel le fichier de configuration de ClientAdapter est stocké.

Aucune (en l'absence de configuration, aucune règle d'accès n'est appliquée).

Section des ports API

Dans la balise ApiPorts, plusieurs définitions ApiPort peuvent s'afficher. Le Tableau 4-2 présente les paramètres pouvant figurer dans une définition ApiPort.

Tableau 4-2 Paramètres de ports API

Paramètre

Description

Valeur par défaut

ListenPort

Socket de port sur lequel se fait l'écoute.

Aucune (obligatoire)

RoutingMode

Mode de routage des demandes (Direct ou MultiDiva).

- Direct : router vers un Manager uniquement (le paramètre Sitename est obligatoire dans ce cas).

- MultiDiva : router à l'aide des commandes de workflow DIVAnet. Les demandes soumises recevront un ID de demande unique fourni par DIVAnet.

MultiDiva

Sitename

Site vers lequel router si le mode Direct est utilisé. Les sites sont définis dans la section DivaManagers (décrite dans le tableau suivant). Ce paramètre n'est obligatoire que pour le mode Direct. S'il est défini, il doit correspondre à l'un des noms de site définis dans la section DivaManagers.

Aucune (obligatoire pour le mode Direct)

LocalAddress

Adresse locale utilisée pour l'envoi à ce Manager (en général, la carte réseau à utiliser). Dans le doute, ne spécifiez pas ce paramètre.

Aucune (facultatif)

WorkflowProfile

Nom du profil de workflow pour les demandes passant par ce port (voir la section Profil de workflow). S'il n'est pas indiqué, le profil de workflow default sera utilisé.

default

(profil par défaut en mode MultiDiva).

Section des Managers DIVArchive

Dans la balise DivaManagers, plusieurs définitions DivaManager peuvent apparaître. Le Tableau 4-3 décrit les paramètres qui peuvent figurer dans une définition DivaManager.

Tableau 4-3 Paramètres de configuration de DivaManagers

Paramètre

Description

Valeur par défaut

Sitename

Nom du site où le Manager est installé. Le nom du site indiqué doit correspondre à ce qui a été configuré dans la base de données DIVAnet ainsi que dans le fichier ManagerAdapter.xml.

Aucune (obligatoire)

ConnectionType

Mode de connexion au Manager (valeurs valides : Socket, WebService).

Socket

Address

Adresse réseau (IP ou nom internet) du Manager.

localhost

Port

Port où les clients se connectent au Manager.

Aucune (obligatoire)

LocalAddress

Adresse locale utilisée pour l'envoi à ce Manager (en général, la carte réseau à utiliser). Dans le doute, ne spécifiez pas ce paramètre.

Aucune (facultatif)

LocalPort

Port local utilisé. Dans le doute, ne spécifiez pas ce paramètre.

0

BaseURL

URL du ManagerAdapter si ConnectionType est défini sur WebService; required.

Aucune (facultatif)

TotalThrottleThreshold

DIVAnet attend que le nombre total de demandes du Manager tombe sous cette limite avant d'envoyer de nouvelles demandes. Cette valeur est utilisée quand ConnectionType est défini sur Socket. Quand le Manager dépasse le nombre de demandes en cours d'exécution, quelle que soit la source (DIVAnet, SPM, connexion API locale), DIVAnet n'envoie plus aucune demande jusqu'à ce le nombre de demandes en cours d'exécution sur le Manager soit inférieur à cette valeur de seuil.

400

SubmittedThrottleThreshold

DIVAnet attend que le nombre de demandes qu'il a lui-même en cours d'exécution sur un Manager tombe sous cette limite avant d'envoyer de nouvelles demandes. Quand le Manager dépasse le nombre de demandes en cours d'exécution envoyées uniquement depuis DIVAnet, DIVAnet n'envoie plus aucune demande jusqu'à ce le nombre de demandes en cours d'exécution sur le Manager envoyées uniquement depuis DIVAnet soit inférieur à cette valeur de seuil.

La valeur zéro a pour effet de mettre tous les messages en file d'attente interne dans DIVAnet. La valeur -1 indique qu'il n'y a aucune limite.

100

Section de base de données DIVAnet

Le Tableau 4-4 présente les paramètres pouvant figurer dans la section DivanetDatabase.

Tableau 4-4 Paramètres DIVAnetDatabase

Paramètre

Description

Valeur par défaut

Address

Adresse IP de la base de données.

localhost

Port

Port utilisé pour accéder à la base de données.

1521

User

Nom d'utilisateur du schéma.

Aucune (obligatoire)

Password

Mot de passe du schéma.

Aucune (obligatoire)

DbSiteId

SID Oracle.

lib5

DbServiceName

Nom du service Oracle. Peut être indiqué à la place de DbSiteId.

Aucune (facultatif)

Section de profil de workflow

Le Tableau 4-5 décrit les paramètres pouvant apparaître dans une section WorkflowProfile.

Tableau 4-5 Paramètres WorkflowProfile

Paramètre

Description

Valeur par défaut

Name

Nom du profil de workflow.

default

AllowDirectRemoteRestores

Autoriser les transferts directs (vers des sources/destinations) à partir de DIVA distants. Définissez ce paramètre sur false pour toujours créer une copie locale du contenu avant restauration.

true

MessageTimeoutMillis

Délai d'expiration par défaut des messages envoyés aux Managers.

15000

(15 secondes)

TotalRequestTimeoutHours

Délai de conservation des demandes avant leur expiration (en heures).

72

PreventArchiveIfInDirectory

Empêcher les nouvelles demandes d'archivage si l'objet existe sur un site. Si ce paramètre est défini sur true, et que l'objet existe sur un site, les demandes d'archivage de cet objet seront rejetées (même si l'objet n'est pas présent sur le site de destination de l'archivage).

true

DeleteRetryIntervalMins

Intervalle entre deux tentatives de suppression de workflow.

5 minutes

DeleteRetryLimitMins

Nombre total de minutes pendant lequel les nouvelles tentatives de suppression de workflow continueront. Les nouvelles tentatives de suppression seront effectuées toutes les DeleteRetryIntervalMins minutes, pendant DeleteRetryLimitMins minutes ou jusqu'à ce que la suppression réussisse.

0 minutes (ne pas effectuer de nouvelle tentative)

IntersiteCopyRetryIntervalMins

Temps d'attente avant une nouvelle tentative de demande de copie. Ce paramètre s'applique uniquement aux demandes de copie.

5 minutes

IntersiteCopyRetryLimitMins

Continuer les nouvelles tentatives de copie jusqu'à ce que la limite de temps totale soit atteinte (ou qu'une tentative aboutisse). Ce paramètre s'applique uniquement aux demandes de copie.

0 minutes (ne pas effectuer de nouvelle tentative)

RestoreRetryAttempts

Dans le cas d'un échec, nombre maximal de nouvelles tentatives à effectuer (en général, nouvelle tentative avec du contenu existant sur un autre site).

3 fois

RestoreRetryIntervalMins

Intervalle entre les tentatives quand DIVAnet effectue une nouvelle tentative avec le même site.

5 minutes

SiteDownRequeueWaitMins

(Avancé) Durée maximale d'indisponibilité d'un site au bout de laquelle les demandes en file d'attente sont routées vers un autre site.

30

BackupArchiveSite

Si le site local est indisponible pour une période étendue (configurée dans SiteDownRequeueWaitMins), site à utiliser pour les archivages à la place du site local. Si l'archivage est soumis et échoue sur le site local, il ne sera pas retenté sur le site de sauvegarde.

Aucune (aucun site de sauvegarde)

ForceGlobalDeleteToSite

Convertit une demande de suppression globale en suppression de site sur le site spécifié.

Aucune (facultatif)

Messages

Une ou plusieurs listes de messages, chacune contenant les messages valides pour le profil de workflow.

NA

Message

Un ou plusieurs noms de message valides :

- AllInfo

- Archive

- Cancel

- CloseObjectsList (legacy)

- Copy

- Delete

- GetArchiveSystemInfo

- GetArrayList

- GetFilesAndFolders

- GetGroupsList

- GetObjectDetailsList

- GetObjectInfo

- GetObjectsList (legacy)

- GetRequestInfo

- GetSourceDestinationList

- GetStoragePlanList

- InitObjectsList (legacy)

- PartialRestore

- Restore

Au moins une balise Message doit être spécifiée.

AllInfo permet l'envoi de tous les messages de demande d'information.

Aucune

(une valeur obligatoire)

UseDefaultMappings

True si le profil de workflow doit inclure tous les mappages définis dans le profil de workflow default.

False

Mappages de transfert site à site (profil de workflow)

La balise Mappings contient plusieurs mappages de transfert de site à site. Un mappage de site à site définit la façon dont un objet est copié d'un site à un autre. Chaque mappage contient des paramètres FromSitename et ToSitename. Chaque mappage définit comment les copies sont effectuées du site FromSitename au site ToSitename.

Chaque mappage contient un paramètre Type qui indique la méthode utilisée pour les transferts (voir Workflow de restauration pour plus d'informations). Les autres paramètres sont des valeurs par défaut utilisées pendant l'exécution de la copie entre sites.

DIVAnet utilisera FromSrcDest comme zone de stockage temporaire et propagera éventuellement vers le site DIVA cible à l'aide du paramètre ToSrcDest. Lors du stockage de contenu, DIVAnet fournit un nom de dossier unique qui est ajouté au FilePathRoot. Après le stockage du contenu dans FromSrcDest, DIVAnet pourra (selon le paramètre Type) :

- archiver le contenu dans le site cible ;

- attendre que le contenu soit archivé avec succès dans le site cible ;

- se terminer sans action supplémentaire.

Remarque :
Pour éviter de spécifier plusieurs fois les mêmes mappages dans la configuration, vous pouvez définir le paramètre de profil de workflow UseDefaultMappings. Le profil de workflow utilisera les mappages du profil de workflow default.

Tableau 4-6 Paramètres de profil de workflow SitetoSiteTransfer

Paramètre

Description

Valeur par défaut

FromSitename

Nom du site d'origine à partir duquel les objets sont copiés. La valeur entrée doit correspondre à l'un des noms de site définis dans la section DivaManagers.

Aucune (obligatoire)

ToSitename

Nom du site de destination vers lequel les objets sont copiés. La valeur entrée doit correspondre à l'un des noms de site définis dans la section DivaManagers.

Aucune (obligatoire)

Type

Le type de transfert :

- Restore : effectuer une restauration et marquer comme transféré.

- RestoreAndArchive : restaurer puis archiver vers le DIVArchive de destination.

- RestoreAndMonitor : restaurer, puis surveiller la destination (utile pour les dossiers de dépôt DFM).

RestoreAndArchive

FromSrcDest

La source/destination à utiliser dans l'étape de restauration de la copie.

Remarque : Oracle recommande de ne pas utiliser la valeur par défaut.

MISSING_MAPPING_TO + FromSitename

ToSrcDest

La source/destination à utiliser dans l'étape d'archivage de la copie.

MISSING_MAPPING_TO + ToSitename

TempDefaultMedia

Média cible à affecter lors de l'exécution d'une copie temporaire ou non persistante de l'objet (effectuée dans certaines opérations de restauration).

La valeur est également utilisée (selon la configuration) quand les utilisateurs de l'API ou de l'interface utilisateur veulent que DIVAnet détermine le média à utiliser (le mot-clé any est utilisé comme média).

Quand RestoreAndMonitor est utilisé avec cette variable, déterminez si l'option AppendMediaToPath est requise.

Aucune (obligatoire pour RestoreAndArchive)

FilePathRoot

Segment de chemin relatif à la racine source/destination. Préfixé pour le nom de dossier unique généré par DIVAnet.

Remote

AdditionalOptions

Options DIVA à utiliser dans les options de restauration/d'archivage.

-axf -rm -delete_fpr

-allow_delete_on_source

AssignDefaultMediaOption

Stratégie à utiliser quand les utilisateurs de l'API ou de l'interface utilisateur décident de laisser DIVAnet choisir quel média utiliser pour les copies. Elle est appelée quand le mot-clé any est utilisé en tant que média.

StoragePlan : utiliser le nom du plan de stockage de l'objet source comme média par défaut.

StoragePlanAndSitename : ajouter au début le nom du site source au plan de stockage (séparé par un trait de soulignement).

TempMedia : utiliser la valeur de TempDefaultMedia en tant que média.

TempMedia

AppendMediaToPath

True si le média cible doit être ajouté, en tant que sous-répertoire, après FilePathRoot (et avant le nom de dossier unique (UniqueFolderName)). Le résultat se présente comme suit :

FilePathRoot / ToMedia / UniqueFolderName

Cette option s'avère utile lors de l'utilisation du type RestoreAndMonitor avec DFM, car DFM peut analyser le nom du média transmis de cette façon.

false

Weighting

Noter ce chemin de transfert en fonction d'autres chemins de transfert, selon la performance, les préférences. Utilisé dans le choix des sites pour la copie et la restauration. La plage valide est comprise entre 0 et 40. Veillez à utiliser des valeurs supérieures à 20, au risque de remplacer d'autres facteurs tels que disque contre bande, statut du site, etc. Une mauvaise utilisation de cette option peut provoquer des problèmes de performance lors des opérations de restauration et peut contribuer à la congestion du réseau WAN.

La valeur par défaut est 10, la valeur locale est augmentée par 10.

Mappages source/destination préférés

Pour calculer le site à utiliser pour les opérations de restauration, DIVAnet préfère en général le site local, dans la mesure où la source/destination est accessible à l'aide du site local. Toutefois, il existe des cas où un autre site est préférable.

La balise Mappings peut contenir une balise SrcDest. Dans la balise SrcDest, une balise Name définit un nom de source/destination. La balise PreferredSitename indique le site préféré à utiliser quand la source/destination est demandée dans une opération de restauration. Plusieurs sections SrcDest peuvent être présentes.

Configuration du service ManagerAdapter

Le fichier de configuration ManagerAdapterConfig.xml contient la configuration pour le service ManagerAdapter. Suivez les étapes ci-après et la description de chaque paramètre dans la configuration ManagerAdapter (chacun des tableaux suivants contient ces informations) pour configurer le service ManagerAdapter.

Filtrage synchronisé par catégorie

DIVAnet peut placer un filtre sur des informations d'objet qui sont extraites par le service DIVAnet DbSync. Ce filtre permet à un site de sélectionner le sous-ensemble d'enregistrements d'objet à synchroniser avec les systèmes DIVAnet en aval. Le filtrage est configuré dans le service ManagerAdapter et c'est ce dernier qui l'exécute.

Remarque :
Les filtres d'objet et la substitution de préfixe de catégorie sont des fonctionnalités avancées qui requièrent d'être soigneusement testées avant d'être implémentées dans des workflows de production. N'ajoutez pas ou ne modifiez pas des filtres d'objet, sans discernement.

Par exemple, le système DIVAnet à New York est configuré pour utiliser et stocker des actifs d'un site à Los Angeles. L'administrateur du site Los Angeles veut s'assurer que les utilisateurs à New York ne voient que les objets correspondant à l'une des trois catégories suivantes : AVID, POST1 et POST2. L'application du filtre suivant dans le fichier de configuration ManagerAdapter du site Los Angeles a pour résultat :

<LocalSitename>LosAngeles</LocalSitename>
<ObjFilter>
<RequestingSitename>NewYork</RequestingSitename>
<Category>AVID</Category>
<Category>POST1</Category>
<Category>POST2</Category>
</ObjFilter>

Avec ce filtre, les objets correspondant aux catégories spécifiées seront synchronisés avec la base de données DIVAnet à New York. Les objets avec d'autres catégories ne seront pas synchronisés. Pour un utilisateur du site New York, les seuls enregistrements d'objet qui existent sur le site Los Angeles sont ceux correspondant au filtre de catégorie configuré. Plusieurs balises ObjFilter peuvent figurer dans le service ManagerAdapter, chacune avec un ensemble de catégories spécifiques d'un site demandeur.

Remarque :
Les filtres de catégorie d'objet n'empêchent pas automatiquement le service ManagerAdapter d'accepter des demandes pour des objets ne correspondant pas au filtre. Les règles d'accès ManagerAdapter empêchent des opérations sur des objets qui ne comportent pas certaines catégories.

Pour empêcher des opérations sur des objets ne correspondant pas au filtre, créez la règle d'accès suivante dans le fichier des règles d'accès ManagerAdapter :

<Include>
<SourceSitename>NewYork</SourceSitename>
<Operation>*</Operation>
<ReqObjectCategory>AVID</ReqObjectCategory>
<ReqObjectCategory>POST1</ReqObjectCategory>
<ReqObjectCategory>POST2</ReqObjectCategory>
</Include>

Cette règle permettra uniquement les demandes du site New York pour des objets correspondant à l'une des trois catégories AVID, POST1 et POST2. Les autres catégories seront refusées si aucune autre règle d'inclusion n'est spécifiée. Si vous définissez des règles d'accès dans le service ManagerAdapter, assurez-vous que le service ClientAdapter soit configuré pour communiquer avec le site en mode WebService.

Configuration de la substitution de préfixe de catégorie

Un problème peut se poser lors de l'utilisation du filtrage de synchronisation par catégorie. En reprenant notre exemple, si New York crée un objet avec une catégorie qui n'est pas présente dans le filtre, et copie cet objet pour Los Angeles, un conflit de dénomination peut survenir. Un objet portant ce nom pourrait déjà exister sur Los Angeles car le système DIVAnet à New York n'a pas connaissance de ces objets. Une solution consiste à fournir des règles d'accès dans New York qui limitent les catégories potentielles pouvant être archivées.

Vous pouvez parvenir à une solution plus flexible en utilisant la substitution de préfixe de catégorie. Cette fonctionnalité filtre les entrées qui sont synchronisées et ajoute un préfixe de catégorie à chaque demande entrante. Cela fournit une fonctionnalité de type espace de noms pour les objets archivés sur un site.

Dans certains workflows, DIVAnet, un seul site doit accepter les objets copiés à partir de plusieurs sites. Il peut donc être difficile d'établir un jeu de catégories unique pour tous les objets du système. Pour résoudre ce problème, utilisez la substitution de préfixe de catégorie. Le filtre d'objet ManagerAdapter suivant garantit que seuls les objets dans Los Angeles avec des catégories commençant par NY001 sont synchronisés avec la base de données DIVAnet de New York.

<LocalSitename>LosAngeles</LocalSitename>
<ObjFilter>
<RequestingSitename>NewYork</RequestingSitename>
<CategoryPrefix>NY001.</CategoryPrefix>
</ObjFilter>

Après l'application du filtre, mais avant que l'objet n'atteigne la destination (New York), le préfixe est éliminé ; les caractères restants servent en tant que catégorie dans la base de données DIVAnet de New York. Par exemple, si la catégorie d'un objet dans Los Angeles est NY001.POST1, la catégorie résultante envoyée à New York sera POST1. De même, chaque fois que le service ClientAdapter de DIVAnet New York envoie des commandes à Los Angeles, le préfixe est de nouveau ajouté.

Cela permet à Los Angeles de stocker des copies de tous les objets provenant de New York sans conflit de dénomination. Cette technique permet à Los Angeles de servir de site de récupération après sinistre pour plusieurs sites. New York n'a pas à modifier sa stratégie de dénomination. New York référence les objets comme il l'a toujours fait, de sorte qu'aucune nouvelle attribution de nom n'est nécessaire sur New York. Un seul préfixe de catégorie est autorisé pour chaque site demandeur.

Pour que cela fonctionne, le service DIVAnet ClientAdapter doit être configuré pour se connecter au site distant en mode WebService. Comme les objets sont essentiellement renommés lors de la copie vers le site avec une substitution de préfixe activée, les objets qui ont été copiés vers le site préalablement n'auront pas de préfixe, ce qui peut poser problème. Une solution consiste à fournir une liste de catégories supplémentaires qui ne sont pas traduites. Une autre solution consiste à demander à des spécialistes de l'installation d'Oracle DIVA de renommer un sous-ensemble d'objets dans le site filtré (autrement dit, d'ajouter le préfixe de catégorie à la catégorie de chaque objet affecté dans la base de données DIVA). Si vous utilisez la substitution de préfixe de catégorie, vous devrez probablement désactiver la vérification de catégorie dans la configuration DIVArchive Actor (contactez le support technique Oracle pour des instructions).

Remarque :
Si vous modifiez un filtre d'objet, il sera presque toujours nécessaire pour le système DIVAnet en aval d'effectuer une resynchronisation du site. Ce système peut à cet effet utiliser l'outil DIVAnetAdmin (voir le Chapitre 6).

Les deux types de filtrage de catégorie peuvent être combinés. Le deuxième filtre suivant (pour Dallas) effectue la substitution de préfixe de catégorie (en utilisant DAL01) sur toutes les catégories sauf POST2 ou POST3. Seuls les enregistrements d'objet présentant le préfixe de catégorie ou la catégorie POST2 ou POST3 seront synchronisés pour 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>

Si vous utilisez cette approche hybride, assurez-vous que les noms d'objet avec des catégories figurant sur la liste (par exemple POST2) ne sont pas ajoutés de nouveau avec le préfixe (par exemple NY001.POST2). Cette stratégie peut être appliquée au moyen de règles d'accès.

Modification du fichier de configuration ManagerAdapter

Les tableaux suivants décrivent les paramètres pouvant figurer dans un fichier de configuration ManagerAdapter. Le fichier se présente au format XML. La colonne de valeur par défaut indique la valeur que le paramètre aura s'il n'est pas spécifié dans le fichier de configuration. Elle indique également si le paramètre est obligatoire ou facultatif.

Pour créer un nouveau fichier de configuration :

1. Accédez au répertoire de base DIVAnet (où DIVAnet est installé).

2. Accédez au dossier Program/conf/divanet/templates, copiez le fichier ManagerAdapterConfig.xml.ini vers le répertoire parent mais sans l'extension .ini (../ManagerAdapterConfig.xml).

3. En utilisant les tableaux ci-dessous comme référence, modifiez les paramètres dans le fichier ManagerAdapterConfig pour configurer le service ManagerAdapter.

Un exemple de fichier de configuration ManagerAdapter figure dans l'Annexe A.

Tableau 4-7 Paramètres de niveau supérieur ManagerAdapter

Paramètre

Description

Valeur par défaut

LocalSitename

Nom du site local. Le nom de site indiqué doit correspondre à ce qui a été configuré dans les bases de données DIVAnet (locale et distante) ainsi qu'à ce qui a été configuré dans les fichiers ClientAdapterConfig.xml et DBSyncConfig.xml. Cette configuration permet aux services ClientAdapter et DbSync de communiquer avec le service ManagerAdapter.

Aucune (obligatoire)

ManagerAddress

Adresse réseau (IP ou nom internet) de DIVArchive Manager.

localhost

ManagerPort

Port où les clients se connectent à DIVArchive Manager.

Aucune (obligatoire)

WebServicePort

Port utilisé pour la réception des messages Web.

Aucune (facultatif)

SSLWebServicePort

True si SSL doit être utilisé pour les connexions de service Web entrantes.

true

AccessRulesFilename

Nom du fichier des règles d'accès. Ce nom de fichier est lié au répertoire dans lequel figure le fichier de configuration ManagerAdapter.

Aucune (en l'absence de configuration, aucune règle d'accès n'est appliquée)

WorkerThreads

Nombre de threads actifs dans les pools de threads DIVAnet. Utilisé pour le réglage des configurations de grande envergure. Dans le doute, ne définissez pas cette valeur.

50

LogDirectory

Dossier dans lequel les fichiers journaux seront générés.

Le dossier log/divanet/ManagerAdapter.

LogLevel

Niveau de détail auquel la journalisation de fichier de suivi intervient (ERROR, WARN, INFO, DEBUG, TRACE).

INFO

Tableau 4-8 Paramètres ManagerDatabase

Paramètre

Description

Valeur par défaut

Address

Adresse IP de la base de données DIVArchive Manager.

localhost

Port

Port utilisé pour accéder à la base de données.

1521

User

Nom d'utilisateur du schéma.

Aucune (obligatoire)

Password

Mot de passe du schéma.

Aucune (obligatoire)

DbSiteId

SID Oracle.

lib5

DbServiceName

Nom du service Oracle. Peut être indiqué à la place de DbSiteId.

Aucune (facultatif)

Un ObjFilter peut être défini pour chaque nom de site demandeur dans le service ManagerAdapter. Le tableau suivant indique les paramètres valides pour le filtre d'objet :

Tableau 4-9 Paramètres ObjectFilter

Paramètre

Description

Valeur par défaut

RequestingSitename

Nom de site du site demandeur d'objets.

Aucune (obligatoire)

Category

Les objets ayant la catégorie indiquée seront synchronisés pour le nom du site demandeur. Plusieurs catégories peuvent s'afficher.

Aucune (facultatif si CategoryPrefix apparaît)

CategoryPrefix

Le préfixe sera ajouté au début de chaque demande reçue via le service ManagerAdapter. Seuls les objets avec le préfixe de catégorie seront synchronisés sur le nom de site demandeur.

Aucune (facultatif si Category apparaît)

Configuration du service DbSync

Le fichier de configuration DBSyncConfig.xml contient la configuration pour le service DbSync. Suivez les étapes ci-après et la description de chaque paramètre pour configurer le service DbSync.

Assurez-vous que le service DbSync est en cours d'exécution lors de l'utilisation du service ClientAdapter. Si DbSync n'est pas en cours d'exécution, certaines demandes qui aboutiraient normalement pourraient se solder par un échec. Par exemple, des restaurations par DIVAnet d'objets récemment archivés pourraient échouer même si de nouvelles demandes d'archivage DIVAnet pourraient aboutir.

Modification du fichier de configuration de DbSync

Les tableaux suivants décrivent les paramètres pouvant figurer dans un fichier de configuration DbSync. Le fichier se présente au format XML. La colonne de valeur par défaut indique la valeur que le paramètre aura s'il n'est pas spécifié dans le fichier de configuration. Elle indique également si le paramètre est obligatoire ou facultatif.

Pour créer un nouveau fichier de configuration :

1. Accédez au répertoire de base DIVAnet (où DIVAnet est installé).

2. Accédez au dossier Program/conf/divanet/templates, copiez le fichier DBSyncConfig.xml.ini vers le répertoire parent mais sans l'extension .ini (../DBSyncConfig.xml).

3. En utilisant les tableaux de description de paramètres ci-dessous comme référence, modifiez les paramètres dans le fichier DBSyncConfig.xml pour configurer DbSync.

Un exemple de fichier de configuration DbSync figure dans l'Annexe A.

Tableau 4-10 Paramètres de niveau supérieur de DbSync

Paramètre

Description

Valeur par défaut

LocalSitename

Nom de site du site DIVAnet local (où DbSync est en cours d'exécution). Le nom de site indiqué doit correspondre à ce qui a été configuré dans la base de données DIVAnet ainsi que ce qui a été configuré dans les fichiers ClientAdapterConfig.xml et ManagerAdapter.xml. Cette configuration permet au service DbSync de communiquer avec le service ManagerAdapter.

Aucune (obligatoire)

LogDirectory

Dossier dans lequel les fichiers journaux seront générés.

Le dossier log/divanet/Dbsync.

LogLevel

Niveau de détail auquel la journalisation du fichier de suivi intervient (ERROR, WARN, INFO, DEBUG, TRACE).

INFO

InternalPollingRateMillis

Fréquence à laquelle les sites sont interrogés. Ne modifiez ce paramètre qu'en cas de lenteur de réseaux et/ou de système.

2000

WebServicePort

Port utilisé pour l'envoi de messages de gestion à DbSync.

Aucune (facultatif)

SSLWebServicePort

True si SSL doit être utilisé pour les connexions de service Web entrantes.

true

Section DivaManager

Dans la balise DivaManagers, plusieurs définitions DivaManager peuvent apparaître. Le Tableau 4-11 décrit les paramètres pouvant figurer dans une section DivaManager.

Tableau 4-11 Paramètres DivaManagers pour DbSync

Paramètre

Description

Valeur par défaut

BaseUrl

URL du service sur la plate-forme DIVA Manager à utiliser pour la synchronisation. Par défaut, elle correspond à l'adresse réseau du ManagerAdapter distant, qualifié par le WebServicePort utilisé par le ManagerAdapter.

Aucune (facultatif)

Sitename

Nom officiel du site à partir duquel synchroniser les informations d'objet. Le nom de site indiqué doit correspondre à ce qui a été configuré dans la base de données DIVAnet ainsi que ce qui a été configuré dans les fichiers ClientAdapterConfig.xml et ManagerAdapter.xml.

Aucune (obligatoire)

Base de données DIVAnet

Configurez les paramètres de base de données DIVAnet comme indiqué dans le Tableau 4-12.

Tableau 4-12 Paramètres DIVAnetDatabase

Paramètre

Description

Valeur par défaut

Address

Adresse IP de la base de données.

localhost

Port

Port utilisé pour accéder à la base de données.

1521

User

Nom d'utilisateur du schéma.

Aucune (obligatoire)

Password

Mot de passe du schéma.

Aucune (obligatoire)

DbSiteId

SID Oracle (identificateur du site).

lib5

DbServiceName

Nom du service Oracle. Peut être indiqué à la place de DbSiteId.

Aucune (facultatif)

Configuration des règles d'accès

Dans DIVAnet, vous utilisez des règles d'accès pour contrôler l'accès que les utilisateurs et applications client ont aux opérations et actifs DIVAnet. Les règles d'accès peuvent être exécutées de trois manières :

- Sur des demandes DIVAnet dans le service ClientAdapter (en mode MultiDiva)

- Sur des demandes DIVArchive dans le service ManagerAdapter

- Sur des demandes DIVArchive qui entrent dans le service ClientAdapter via un port en mode Direct

Pour exécuter les règles d'accès, vous devez définir le paramètre AccessRulesFilename dans le fichier de configuration de ClientAdapter et/ou de ManagerAdapter. Vous devez indiquer le nom du fichier sans le chemin d'accès. DIVAnet suppose que le fichier sera situé dans le même répertoire que le fichier de configuration de ClientAdapter.

Méthodes d'exécution des règles d'accès

Les jeux de règles d'accès définis dans le service ClientAdapter (mode MultiDiva) assurent le contrôle d'accès sur des demandes DIVAnet (reçues localement). Les jeux de règles d'accès définis dans la configuration de ManagerAdapter assurent le contrôle d'accès sur des demandes DIVArchive (soumises pour satisfaire une demande DIVAnet). Deux niveaux de contrôle d'accès permettent aux règles de niveau service d'être configurées où les demandes sont initiées et aux règles spécifiques du site d'être appliquées en tant qu'exceptions aux stratégies de niveau service.

Les jeux de règles d'accès définis dans le service ClientAdapter (mode Direct) assurent le contrôle d'accès sur des demandes DIVAnet ou sur des demandes DIVArchive, selon que le système distant est une autre instance DIVAnet ou un système DIVArchive. Dans ce mode, des types d'opération supplémentaires sont disponibles pour utilisation dans des jeux de règles. Ces opérations correspondent à des demandes spécifiques de DIVArchive et sont détaillées ci-après.

Exemple d'archivage

Examinons rapidement un exemple pour mieux comprendre ces règles. La règle suivante permet des opérations d'archivage pour des utilisateurs se connectant en tant qu'administrateur ou opérateur à partir de la source/destination DATA_EXP_PDAT1 ou VID_FTP_3, et d'archiver sur un média HDFeatures ou spm (vous verrez que l'ordre des attributs n'est pas important), nommé avec une catégorie contenant le mot 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>

Exemple de copie

Dans les deux règles suivantes, les utilisateurs invités (guest) à partir du profil de workflow GUI ne sont pas autorisés à effectuer des copies de diva2 vers diva3 ou inversement.

<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>

Vous avez utilisé deux règles ici parce que vous ne vouliez pas limiter de façon explicite les opérations de copie qui se produisent dans le même site. Par exemple, quelqu'un sur le site diva2 veut copier un objet (en utilisant DIVAnet) vers une nouvelle bande ; dans ce cas, les noms des sites source et cible sont tous les deux diva2. Si vous disposiez d'une règle unique contenant tous les attributs SourceSitename et TargetSitename, vous pourriez exclure les copies de diva2 vers diva2 et de diva3 vers diva3.

Vous n'avez pas encore terminé. La copie n'aboutira pas si vous n'avez pas au moins une règle d'inclusion qui correspond.

<Include>
<Operation>Copy</Operation>
<WorkflowProfile>GUI</WorkflowProfile>
<Username>guest</Username>
<Operation>ApiConnect</Operation>
</Include>

Dans ce cas, une règle d'inclusion très générale vous donne la possibilité d'effectuer des copies où vous voulez, sauf de diva2 vers diva3 et inversement. En fait, vous n'aviez pas besoin d'une règle d'exclusion. Parfois, en revanche, il est plus facile d'utiliser des règles d'exclusion. Gardez à l'esprit que si une règle d'exclusion correspond à une opération, cette opération sera refusée, même si une ou plusieurs règles d'inclusion correspondent.

Règles d'inclusion et d'exclusion

Pour résumer, il existe deux types de règles : inclusion et exclusion. L'accès est refusé pour toutes les demandes sauf si au moins une règle d'inclusion correspond à l'opération sur le point d'être exécutée. En revanche, si une règle d'exclusion correspond, l'opération est automatiquement rejetée, quelles que soient les règles d'inclusion qui correspondent.

Types d'attribut

Sur des demandes telles que la suppression, la copie, la restauration, la restauration de fichiers partielle, l'annulation et l'archivage, DIVAnet exécute le jeu complet de règles d'accès pour voir si l'opération est autorisée. Il examine des variables telles que :

- Attributs d'auteur : profil de workflow de la connexion, nom de l'utilisateur qui a envoyé le message, adresse IP de l'auteur.

- Attributs de demande : source/destination, noms des sites source/cible, média demandé, commentaires, etc. Ces attributs sont dérivés de la demande elle-même. La plupart ont le préfixe Req.

- Attributs d'objet : média(s) sur lesquels l'objet est stocké, plan de stockage, taille de l'objet, etc. Ces attributs sont dérivés de l'objet en cours de traitement par une opération. La plupart ont le préfixe Obj.

La règle suivante combine ces trois types d'attribut. Elle permet à un utilisateur diva d'effectuer une suppression de site sur New York uniquement si l'objet existe sur Los Angeles.

<Include>
<Username>diva</Username>
<Operation>Delete</Operation>
<SubType>SiteDelete</SubType>
<TargetSitename>NewYork</TargetSitename>
<ObjOnSite>LosAngeles</ObjOnSite>
</Include>

Règles pour les demandes DIVAnet (ClientAdapter)

Des demandes DIVAnet sont générées quand des demandes sont reçues en mode MultiDiva. Des règles d'accès peuvent être créées pour ces opérations DIVAnet. Voici les détails de certains attributs spécifiques des demandes DIVAnet.

Opérations Connect

Les opérations ApiConnect et WebConnect sont des opérations spéciales qui doivent être incluses pour établir une connexion au service ClientAdapter.

- ApiConnect : cette opération régit la capacité à se connecter au service ClientAdapter au moyen d'une connexion de socket API client. Elle est obligatoire pour les connexions d'API DIVA.

- WebConnect : cette opération régit la capacité des applications à se connecter via des connexions Web (DIVAnetUI et DivanetAdmin). Elle est obligatoire pour les connexions DIVAnetUI.

Quand ces opérations sont confrontées aux règles, gardez à l'esprit que seuls les attributs d'auteur seront présents pour la mise en correspondance. Par exemple, le paramètre TargetSitename ne sera pas mis en correspondance si des règles d'accès sont exécutées lors de l'opération ApiConnect, car l'attribut n'est simplement pas présent quand un client se connecte.

Sous-type (pour suppression)

L'opération de suppression comporte un champ SubType qui représente un sous-type de l'opération. Vous pouvez inclure le champ SubType dans des règles avec l'opération de suppression, en indiquant plusieurs paramètres SubType, le cas échéant. Les valeurs pour SubType sont :

- GlobalDelete : correspond si l'opération de suppression à effectuer est une suppression globale d'un objet sur tous les sites. Cela correspond également à une opération de suppression de site qui consiste à supprimer tous les objets restants dans DIVAnet.

- SiteDelete : correspond si l'opération de suppression est une suppression de toutes les instances sur un site donné (le nom du site peut être mis en correspondance dans des règles à l'aide du paramètre TargetSitename). En outre, une opération aura ce SubType si le demandeur supprime une seule instance, mais qu'il s'agit de la dernière instance de l'objet sur ce site.

- InstanceDelete : cette opération supprime une seule instance sur un site, alors qu'il en existe d'autres sur le site en question.

La spécification de ce paramètre dans des règles s'avère utile pour appliquer efficacement la portée des opérations de suppression autorisées.

Règles pour les demandes DIVArchive (ManagerAdapter)

DIVAnet autorise l'exécution des règles d'accès sur des demandes DIVArchive également. Les règles d'accès définies dans le service ManagerAdapter spécifient quelles opérations DIVArchive (envoyées pour satisfaire des demandes DIVAnet) sont autorisées. Seules les opérations valides pour des demandes DIVAnet peuvent être spécifiées dans des jeux de règles. Dans les jeux de règles ManagerAdapter, les attributs WorkflowProfile, TargetSitename et SubType ne sont pas valides.

Comme dans les jeux de règles ClientAdapter, l'opération WebConnect doit être autorisée pour que des connexions soient établies avec le service ManagerAdapter. Cela s'étend également aux opérations DbSync. L'attribut SourceSitename correspond au site spécifique qui fait une demande. L'opération ApiConnect n'est pas disponible dans les règles d'accès ManagerAdapter.

Mise en correspondance de règle

La mise en correspondance d'une règle implique la comparaison des attributs de la règle aux valeurs réelles de chaque demande, d'un objet de mise en correspondance ou de l'émetteur de la demande. Les caractères génériques sont autorisés (utilisez un astérisque (*) comme caractère générique). Les noms de balise ne sont pas sensibles à la casse, mais la plupart des valeurs font la distinction entre majuscules et minuscules. La balise Operation est requise dans chaque règle. Vous pouvez spécifier une balise Operation contenant un astérisque (*) pour indiquer que la règle s'applique à toutes les opérations. En revanche, vous devez faire attention quand vous procédez ainsi car tous les attributs ne sont pas valides pour toutes les opérations.

Les attributs distincts d'une règle (d'inclusion ou d'exclusion) sont reliés par un opérateur AND logique dans le processus de mise en correspondance. Toutefois, un seul attribut spécifié plus d'une fois dans une règle provoque la jointure de ces attributs par un opérateur OR logique dans une seule expression.

Lors de la mise en correspondance de l'opération demandée avec une règle d'accès, DIVAnet détermine si l'attribut de la règle est applicable pour l'opération à effectuer. Si tel n'est pas le cas, l'attribut n'est pas utilisé dans la comparaison.

Jeux de règles et valeurs par défaut

Les règles peuvent être regroupées dans des jeux de règles. Chaque règle d'inclusion/d'exclusion doit figurer à l'intérieur de balises Ruleset. Chaque opération DIVAnet entrante est mise en correspondance avec tous les jeux de règles. Les jeux de règles sont utiles car ils peuvent avoir des attributs qui servent de valeurs par défaut pour toutes les règles qu'ils contiennent. Lors de la mise en correspondance, chaque attribut Ruleset par défaut est incorporé implicitement à chaque règle enfant, comme s'il avait été spécifié directement dans la règle. Il est courant d'utiliser un profil de workflow comme attribut par défaut pour les jeux de règles, car le profil de workflow est alimenté pour chaque opération DIVAnet demandée.

Les attributs suivants peuvent être définis par défaut dans un jeu de règles :

- Username

- NetAddress

- WorkflowProfile (dans des règles ClientAdapter)

Autre exemple

L'exemple suivant autorise les utilisateurs connectés à un WorkflowProfile ayant la valeur GUI de consulter des demandes et des actifs, et d'effectuer des suppressions d'instances individuelles sur le site diva1. Gardez à l'esprit qu'un paramètre SubType d'une opération InstanceDelete rejettera toute suppression qui risquerait de supprimer la dernière instance d'un objet particulier sur un site.

La seconde partie de l'exemple empêche toutes les connexions, qu'il s'agisse de connexions Web ou d'API, provenant du sous-réseau 172.53. Toutes les opérations sont concernées, quel que soit leur profil de workflow.

<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>

Paramètres de jeu de règles

Le Tableau 4-13 décrit les paramètres qui peuvent apparaître dans la section Ruleset.

Tableau 4-13 Paramètres de jeu de règles

Paramètre

Description

Valeur par défaut

WorkflowProfile

Cet attribut, défini dans la configuration de ClientAdapter, est le nom d'un groupe de travail ou d'un ensemble d'applications qui accèdent à DIVAnet. Cet attribut fait partie de chaque règle du jeu.

Aucune (facultatif)

Username

Nom d'utilisateur transmis dans l'API ou spécifié dans la demande Web. Cet attribut fait partie de chaque règle du jeu.

Aucune (facultatif)

NetAddress

Adresse réseau (IP ou nom internet) de la connexion distante. Il peut s'agir de l'adresse d'une passerelle ou d'un routeur et non de l'adresse de l'émetteur. Cet attribut fait partie de chaque règle du jeu.

Aucune (facultatif)

Exclude

Règle qui refuse une autorisation si elle correspond à l'opération DIVAnet.

Aucune (facultatif)

Include

Règle qui permet l'autorisation si elle correspond à l'opération DIVAnet.

Aucune (facultatif)

Paramètres de règle d'inclusion ou d'exclusion

Vous pouvez spécifier des attributs de règle qui figurent dans les demandes. Par exemple, ReqMedia correspondra au média et (ou) au plan de stockage spécifié dans une demande (opération).

De même, vous pouvez spécifier des attributs de règle qui correspondent à l'objet archivé que la demande traite. Par exemple, si un objet donné est spécifié dans une opération de suppression, ObjHasMedia mettra en correspondance n'importe quel média faisant actuellement partie de cet objet archivé, quel que soit le média transmis dans la demande.

Le Tableau 4-14 décrit les paramètres pouvant apparaître dans une section de règle Include ou Exclude.

Tableau 4-14 Paramètres opérationnels de règle (d'inclusion ou d'exclusion)

Paramètre

Description

Valeur par défaut

Operation

Nom de l'opération DIVAnet à mettre en correspondance :

- Archive

- Copy

- Restore

- PartialRestore

- Delete

- Cancel

- ApiConnect

- WebConnect

- ChangeConfig

Il existe des opérations supplémentaires disponibles pour les opérations DIVArchive en mode Direct :

- CopyToNew

- InsertTape

- EjectTape

- AssociativeCopy

- TranscodeArchived

- TransferFiles

- ServerDelete

- ChangePriority

Aucune (facultatif)

Username

Nom d'utilisateur de l'utilisateur d'API connecté et (ou) de l'utilisateur du service.

Aucune (facultatif)

WorkflowProfile

Nom du profil ClientAdapter.

Aucune (facultatif)

NetAddress

Adresse IP de l'application d'API et (ou) de l'utilisateur.

Aucune (facultatif)

SourceSitename

Nom de site source de l'opération. Certaines opérations n'ont pas de nom de site source (par exemple, la commande Archive a une source/destination comme source). Si la demande est retentée sur un autre site, cette valeur changera et la règle entière sera réévaluée. Quand cet attribut figure dans des règles ManagerAdapter, il correspond au site qui a soumis la demande.

Aucune (facultatif)

TargetSitename

Nom de site cible de l'opération. Certaines opérations n'ont pas de nom de site cible (par exemple, la commande Restore a une source/destination comme cible, mais pas un site). Si la demande est retentée sur un autre site, cette valeur changera et la règle entière sera réévaluée.

Aucune (facultatif)

SubType

Type d'opération en mode MultiDiva (la commande Delete comprend GlobalDelete, SiteDelete et InstanceDelete).

Aucune (facultatif)

Tableau 4-15 Paramètres de demande de règle (d'inclusion ou d'exclusion)

Paramètre

Description

Valeur par défaut

ReqObjectName

Nom de l'objet en cours de traitement.

Aucune (facultatif)

ReqObjectCategory

Catégorie de l'objet (dans DIVArchive, elle fait partie du nom formel de l'objet).

Aucune (facultatif)

ReqSourceDest

Source/destination spécifiée dans la demande.

Aucune (facultatif)

ReqComments

Champ de commentaires dans la demande.

Aucune (facultatif)

ReqMedia

Média qui a été demandé dans le cadre de l'opération/de la demande (le nom de site ne doit pas être ajouté). Gardez à l'esprit que Storage Plan peut être transmis en tant que média demandé.

Aucune (facultatif)

ReqOptions

Champ d'options dans la demande.

Aucune (facultatif)

Tableau 4-16 Paramètres d'objet de règle (à inclure ou à exclure)

Paramètre

Description

Valeur par défaut

ObjOnSite

Correspond si l'objet existe sur le site spécifié.

Aucune (facultatif)

ObjNotOnSite

Correspond si l'objet n'existe PAS sur le site spécifié.

Aucune (facultatif)

ObjHasMedia

Correspond à tout média sur tout site.

Aucune (facultatif)

ObjHasStoragePlan

Correspond au plan de stockage sur tout site (ObjStoragePlanSite peut limiter à un site).

Aucune (facultatif)

ObjStoragePlanSite

Limite le plan de stockage indiqué à un site spécifique.

Aucune (facultatif)

ObjHasSizeGbLessThan

Correspond si la taille totale de l'objet en Go fractionnaires est inférieure à la valeur spécifiée.

Aucune (facultatif)

ObjHasSizeGbGreaterThan

Correspond si la taille totale de l'objet en Go fractionnaires est supérieure à la valeur spécifiée.

Aucune (facultatif)

Ajout de variables de script à un fichier de configuration

DIVAnet autorise le remplacement de variable dans des fichiers de configuration pour faciliter la configuration de plusieurs fichiers script. Quand le modèle ${variable_name} est détecté dans une valeur XML (les variables ne sont pas valides dans les noms de balise), la valeur de la variable est remplacée quand DIVAnet lit le script. La valeur peut être extraite d'une variable d'environnement ou affectée directement dans le script.

Si le nom de variable dans le script est identique à celui d'une variable d'environnement, la valeur de cette variable sera remplacée dans le script. Vous pouvez aussi définir des valeurs de variables au début de chaque script à l'aide de la balise Variable. La syntaxe est : <Variable name="LocalSitename" value="diva1"/>. Quand DIVAnet lit un script de configuration, il vérifie si des variables utilisées dans le script ont été définies au début. Si tel n'est pas le cas, il recherche une variable d'environnement ayant le même nom que la variable.

Pour des raisons de commodité, un fichier script nommé divanetEnv.conf a été créé dans le répertoire de base DIVAnet, dans le sous-dossier Program\conf\divanet\wrapper. Il est possible de centraliser la définition des variables dans ce fichier de configuration afin qu'elles soient disponibles pour tous les services DIVAnet. En cas de modification de valeur et de redémarrage du service, les modifications feront l'objet d'une nouvelle lecture. Reportez-vous au fichier divanetEnv.conf pour des exemples de variables.

5 Utilisation de l'interface utilisateur DIVAnet

- Prérequis

- Démarrage de l'application DIVAnetUI

- Connexion à DIVAnet

- Affichage des actifs

- Affichage des demandes

- Copie d'un objet

- Suppression d'un objet

- Restauration d'un objet

- Modification du fichier de configuration

Prérequis

Pour utiliser l'application DIVAnet :

- Le service ClientAdapter doit être configuré et en cours d'exécution côté serveur.

- Si vous voulez effectuer des copies intersite dans DIVAnetUI, assurez-vous que les mappages ClientAdapter site à site sont configurés.

- Pour voir les informations d'actif les plus récentes, il vous faudra configurer et exécuter le service DbSync.

Remarque :
DIVAnet 2.x ne prend plus en charge l'interface graphique (GUI) de contrôle de DIVArchive ; utilisez DIVAnetUI à la place. DIVAnet 2.x ne transfère pas et ne prend pas en charge les messages de l'interface graphique (GUI) de contrôle, que ce soit en mode MultiDiva ou Direct.

Démarrage de l'application DIVAnetUI

Pour démarrer l'application DIVAnetUI dans Windows, cliquez sur le lien de raccourci fourni. Ce lien se trouve dans le répertoire de base DIVAnet, dans le sous-dossier Program/divanet/bin. Vous pouvez le copier vers le bureau ou le menu de démarrage de Windows.

Ouvrez une fenêtre de terminal et appelez le script DIVAnetUI.sh pour lancer DIVAnetUI dans Linux.

Reportez-vous au Chapitre 3 pour plus de détails sur l'installation de DIVAnetUI.

Connexion à DIVAnet

Après avoir démarré l'application DIVAnet :

1. Cliquez sur l'onglet Requests ou Assets pour ouvrir une invite pour l'URL du serveur DIVAnet.

2. Entrez l'URL du serveur DIVAnet et cliquez sur OK.
Par défaut, l'URL correspond au nom d'hôte du service ClientAdapter, suivi d'un caractère deux-points, suivi du WebServicePort de ClientAdapter. La valeur que vous entrez sera persistante dans le fichier des propriétés DIVAnetUI. Exemple :

https://127.0.0.1:9801

Si une erreur de connexion survient, un message s'affiche dans l'angle inférieur droit de l'écran. Cliquez sur le bouton Change URL pour afficher une invite pour une nouvelle URL.

Affichage des actifs

Pour afficher une liste des actifs, cliquez sur l'onglet Assets. Les 400 premiers actifs seront affichés dans le panneau de gauche. Le nom de l'actif sera indiqué en bleu, suivi de la catégorie de l'objet.

Par défaut, les actifs sont présentés par ordre de nom d'objet. Sélectionnez un actif pour afficher les détails dans le panneau de droite.

Panneau Asset Details

Le panneau Asset Details est divisé en trois sections : Global Object Parameters en haut, Sites Table au milieu et le tableau Asset Filenames en bas. Voici les descriptions de certains paramètres et sections du panneau Asset Details :

- Object Parameters : les paramètres en haut du panneau Details incluent la taille totale de l'objet, la date d'archivage, le nombre de copies (instances) et les commentaires.

- Last Verified Date : représente la dernière vérification par checksum de l'objet sur bande, sur tout site. Si aucune instance de bande n'existe, la dernière vérification de l'objet sur disque est renvoyée. Si l'objet n'a jamais été vérifié sur un média archivé, le champ est vide.

- Alerts : toutes les alertes d'objet seront affichées directement sous le champ Comments. Par exemple, si DIVAnet détecte que deux sites ont des objets portant le même nom, mais un contenu différent, une alerte s'affichera.

- Active Requests : sur le panneau Asset Details, le texte en vert (au-dessus de Sites Table) indique d'éventuelles demandes DIVAnet en cours d'exécution sur l'objet sélectionné. Il est utile de consulter ce champ avant d'émettre des demandes de copie ou de suppression. Cette valeur n'est actualisée que quand vous appuyez sur le bouton Search (voir Recherche d'actifs).

- Sites Table : chaque site contenant des instances de l'objet est affiché dans le tableau des sites. Chaque site peut contenir une ou plusieurs instances d'objet. Les objets de chaque site ont un plan de stockage (Storage Plan) et des dates d'archivage initial (que vous pouvez utiliser dans le panneau de recherche (Search)).
Une icône ressemblant à une maison indique que le site est le site local. Une icône violette indique que les actifs du site sont en lecture seule et qu'il n'est pas possible d'effectuer des demandes dessus. Une icône ressemblant à un globe indique que le site n'est pas local.

- Asset Filenames Table : les noms de fichier qui composent l'actif archivé figurent en dessous du tableau des sites. Les noms de fichier sont organisés en pages et triés selon l'ordre où ils ont été archivés. Les noms de fichier pour des objets archivés complexes ne peuvent pas être affichés dans ce panneau.

Recherche d'actifs

DIVAnetUI offre de puissantes fonctionnalités de recherche d'objets. Cliquez sur le bouton Search sur la gauche pour ouvrir le panneau Asset Search.

Le panneau Asset Search permet de rechercher des actifs de plusieurs façons. Certains paramètres sont sélectionnables, ce qui signifie que vous pouvez sélectionner à la fois un attribut et une valeur. Chaque valeur entrée pose une restriction supplémentaire sur les actifs renvoyés. Les caractères génériques sont autorisés dans tous les champs de recherche à l'exception des champs de date et heure.

Voici une liste de paramètres utiles pour rechercher des actifs :

- Archive Date Search : DIVAnet permet à l'utilisateur d'effectuer une recherche selon la date à laquelle un objet a été archivé dans un site DIVA. Pour restreindre la recherche aux objets qui ont une date d'archivage comprise dans une plage, il est possible de spécifier une date et une heure de début et de fin. Cliquez sur l'icône de calendrier pour sélectionner une date puis remplacez la valeur d'heure dans le champ de texte par l'heure voulue. Un objet peut avoir plusieurs dates d'archivage (une pour chaque site) et cette recherche permet de trouver celles qui existent dans la plage indiquée.

- Object Name / Category : un nom d'actif se compose de deux champs, le nom d'objet et la catégorie d'objet. La catégorie est la seconde partie du nom formel d'un objet.

- Site Search : certains termes de recherche peuvent être sélectionnés par l'utilisateur, notamment les paramètres de recherche de site. Vous pouvez rechercher des objets qui sont sur un site, ne figurent pas sur un site ou ont une copie de bande sur un site. Cette recherche s'avère utile pour déterminer, par exemple, quels objets doivent être copiés vers d'autres sites.

- Other Search Parameters : vous pouvez également lancer des recherches sur d'autres paramètres tels que nom de fichier, taille d'objet, commentaires et média.
Vous pouvez sélectionner le même paramètre (par exemple, media) plusieurs fois et fournir des valeurs différentes. Par défaut, les valeurs multiples sont reliées à toutes les autres valeurs de l'interrogation à l'aide d'un opérateur ET logique. Par exemple, si vous effectuez une recherche avec les paramètres Sitename=Site A et Sitename=Site B, les résultats comprendront les objets qui figurent à la fois sur Site A et Site B.

En revanche, si vous cochez la case OR Like Query Params, les valeurs seront jointes par un opérateur OU logique. Par exemple, vous pouvez rechercher des objets présentant le support POST1 OU PLAYOUT (ou les deux).

- Ordering : vous pouvez trier les objets par nom d'objet (valeur par défaut), catégorie, date d'archivage et taille d'objet. Lors de l'utilisation d'autres méthodes de tri, vous pouvez constater un ralentissement des performances de recherche.

Couper et coller des détails d'actif

Vous pouvez copier la plupart des valeurs du panneau Asset Details dans le presse-papiers en cliquant deux fois sur la valeur voulue. Dans le panneau Asset Search, un clic droit sur un champ de texte affiche un menu. Le menu contient une option de collage, ce qui vous permet de coller les éléments du presse-papiers dans le champ de texte. Vous pouvez également utiliser Ctrl-V pour coller les informations.

Affichage des demandes

Cliquez sur l'onglet Requests pour afficher un tableau des demandes DIVAnet dans le panneau de gauche. Ce tableau est trié en fonction de la date à laquelle chaque demande a été soumise. Pour chaque demande, le tableau indique d'où provient le contenu et vers où il est déplacé (le cas échéant). Un libellé (SD) ajouté indique que le contenu est déplacé depuis ou vers une source/destination. Autrement, le contenu est déplacé depuis ou vers un site DIVAnet.

Affichage de la progression des demandes (mises à jour live)

Les mises à jour live des demandes sont activées au démarrage de DIVAnetUI. Si la demande qui est interrogée est actuellement en cours d'exécution, sa progression sera automatiquement mise à jour sur l'écran. Vous pouvez appliquer des filtres pour réduire le nombre de demandes qui sont dynamiquement mises à jour sur l'écran. Vous pouvez arrêter les mises à jour live de la progression en indiquant une date et une heure de fin dans le panneau Filter. Voir Filtrage des demandes.

Affichage des détails de demande

Pour afficher les détails d'une demande, cliquez dessus dans le tableau. Les détails incluent des informations telles que la priorité de la demande, la qualité de service, les noms de site source et cible et le média (le cas échéant). En outre, une liste des événements de niveau demande est présentée. Ces événements indiquent les étapes que suit DIVAnet pour satisfaire la demande, ainsi que les erreurs détectées.

Annulation de demandes

Un clic droit sur une demande du tableau permet d'afficher l'option Cancel. Si une demande est annulée, une autre demande (d'annulation) est générée et affiche le statut de la tentative d'annulation.

Filtrage des demandes

DIVAnetUI offre de puissantes fonctionnalités de filtrage des demandes. Cliquez sur le bouton Filter sur la gauche pour ouvrir le panneau Request Filter.

Le panneau Request Filter contient les paramètres utilisés pour filtrer la liste des demandes. Deux de ces paramètres peuvent être sélectionnés par l'utilisateur. Chaque valeur entrée pose une restriction supplémentaire sur les actifs renvoyés. Les caractères génériques sont autorisés dans tous les champs de recherche à l'exception des champs de date et heure et du champ Request ID.

Remarque :
Contrairement au panneau Asset Search, vous ne pouvez pas lancer une recherche sur le même attribut plus d'une fois.

Voici quelques termes de recherche qui peuvent être appliqués à la liste des demandes :

- Request ID : les demandes DIVAnet sont identifiées de façon unique par un ID de demande. DIVAnet permet le filtrage par ID de demande ou par nom d'objet en cours de traitement.

- Request Submission Date : il est possible de spécifier une plage de dates/heures de début et de fin qui renvoie uniquement les demandes soumises dans la plage indiquée. Cliquez sur l'icône de calendrier pour sélectionner une date. L'heure locale actuelle (de l'ordinateur) est automatiquement indiquée dans le champ de texte. Vous pouvez remplacer la valeur d'heure dans le champ de texte par l'heure voulue. Si une date et une heure de fin sont indiquées, aucune mise à jour du statut ou de la progression ne sera affichée à l'écran. Supprimez la date et l'heure de fin pour activer de nouveau les mises à jour live.

- Request Type : il est possible d'appliquer des filtres au type de demande. Chaque type peut être activé ou désactivé individuellement. De cette façon, les filtres peuvent assurer (par exemple) que seuls les archivages et les suppressions figurent dans la liste.

- Request Status : il est possible d'appliquer des filtres au statut de demande. De cette façon, les filtres peuvent assurer (par exemple) que seules les demandes qui sont en attente (Pending) ou en cours d'exécution (Running) sont affichées.

- Other Search Parameters : vous pouvez également appliquer des filtres sur d'autres paramètres tels que Media, Source/Destination et Comments.

Couper et coller des détails de demande

Vous pouvez copier la plupart des valeurs du panneau Request Details dans le presse-papiers en cliquant deux fois sur la valeur voulue. Dans le panneau Request Filter, si vous faites un clic droit sur un champ de texte, vous affichez un menu. Le menu contient une option de collage, ce qui vous permet de coller les éléments du presse-papiers dans le champ de texte. Vous pouvez également utiliser Ctrl-V pour coller les informations.

Copie d'un objet

DIVAnet peut copier des objets d'un site à un autre, ou peut copier l'objet vers un autre média d'archivage sur le même site (en créant une nouvelle instance d'objet).

1. Dans le tableau d'actifs (Asset Table), sélectionnez les objets à copier.

2. Au-dessus de Asset Table, cliquez sur le bouton Copy.
Une boîte de dialogue s'affiche et présente les objets sélectionnés.

3. Sélectionnez un site cible (Target Site), un média/plan de stockage (Media/Storage Plan) et une priorité (Priority).

- Si l'objet existe déjà sur le site vers lequel vous effectuez la copie, DIVAnet créera une autre instance avec le média d'archivage que vous sélectionnez. Dans ce cas, la spécification d'un média/plan de stockage provoquera l'échec de la demande de copie pour cet objet, car l'objet sur ce site a déjà un plan de stockage.

- Si vous sélectionnez Selected By DIVAnet pour l'option Media/Storage Plan, DIVAnet choisira un média approprié pour la copie. Si l'objet existe déjà sur le site vers lequel vous effectuez la copie, DIVAnet ne créera pas une autre instance sur ce site.

4. Cliquez sur Submit.

5. Cliquez sur Monitor Requests ou sur Close.
Si vous sélectionnez Monitor Requests, vous verrez s'afficher la fenêtre Requests View dans laquelle vous pouvez surveiller les demandes de copie DIVAnet pour chaque objet que vous avez sélectionné.

Suppression d'un objet

Vous pouvez supprimer un objet d'un site donné ou de tous les sites.

1. Dans le tableau d'actifs (Asset Table), sélectionnez les objets à supprimer.

2. Au-dessus de Asset Table, cliquez sur Delete.
Une boîte de dialogue s'affiche et présente les objets sélectionnés.

3. Sélectionnez un site cible (Target Site) et une priorité (Priority).
Vous pouvez sélectionner un site donné ou tous les sites.

4. Cliquez sur Submit.

5. Cliquez sur Monitor Requests ou sur Close.
Si vous sélectionnez Monitor Requests, vous verrez s'afficher la fenêtre Requests View dans laquelle vous pouvez surveiller les demandes de suppression DIVAnet pour chaque objet que vous avez sélectionné.

Restauration d'un objet

Il est possible de restaurer des objets dans une source/destination particulière en procédant comme suit :

1. Dans le tableau d'actifs (Asset Table), sélectionnez les objets à restaurer.

2. Au-dessus de Asset Table, cliquez sur Restore. Une boîte de dialogue apparaît et affiche les objets sélectionnés.

3. Entrez une Source/Destination et sélectionnez une priorité dans Priority.

4. Vous pouvez éventuellement spécifier des options de restauration dans le champ Options, ou (et) un chemin de destination relatif à la source/destination.

5. Cliquez sur Monitor Requests ou sur Close.
Si vous choisissez l'option Monitor Requests, vous êtes conduit vers l'affichage Requests View où vous pouvez surveiller les demandes de restauration de DIVAnet pour chaque objet sélectionné.

Modification du fichier de configuration

Le script de démarrage standard de DIVAnetUI est configuré pour charger un fichier de propriétés au démarrage. Vous trouverez ce fichier de configuration dans le répertoire de base DIVAnet (Program/conf/divanet/divanetui.properties).

Remarque :
L'application DIVAnetUI a besoin d'autorisations en écriture sur le fichier de propriétés car elle enregistre chaque modification apportée à l'URL directement dans ce fichier.

Vous pouvez configurer une URL par défaut dans ce fichier. Cette URL doit faire référence à l'adresse réseau du service ClientAdapter et au WebServicePort (configuré dans le fichier ClientAdapter.xml). Les serveurs Web locaux et les routeurs peuvent modifier l'adresse et (ou) le port nécessaires dans l'URL.

Dans ce fichier, vous pouvez configurer les paramètres suivants :

- Logging Parameters : DIVAnetUI écrit un fichier journal, et vous pouvez changer le niveau de journalisation par défaut en modifiant le paramètre logLevel.

- Default Url : URL qui se connecte à DIVAnet (service ClientAdapter). Chaque fois que l'URL est modifiée dans l'application, elle est mise à jour ici dans le fichier de configuration.

- Max Objects to Query : nombre maximal d'objets à extraire dans la vue des actifs (Assets View).

- Max Requests to Query : nombre maximal de demandes à extraire dans la vue des demandes (Requests View).

- Username : nom utilisateur (par exemple, diva) à transmettre à DIVAnet, qui peut être utilisé dans les règles d'accès.

6 Administration de DIVAnet

Ce chapitre décrit l'administration de DIVAnet.

Utilisation de l'utilitaire DIVAnetAdmin

DIVAnetAdmin est un outil de ligne de commande simple présentant des options pour administrer DIVAnet. Cet utilitaire ne peut être exécuté que sur le serveur sur lequel les services ClientAdapter et DbSync s'exécutent.

Pour démarrer l'utilitaire, ouvrez une fenêtre de commande et accédez au sous-répertoire Program/divanet/bin depuis le répertoire de base DIVAnet. Entrez l'une des commandes suivantes pour lancer l'utilitaire :

Windows :

DIVAnetAdmin.bat ClientAdapterWebUrl DbSyncWebUrl

Linux :

DIVAnetAdmin.sh ClientAdapterWebUrl DbSyncWebUrl

Remarque :
Si vous n'indiquez pas les arguments d'URL, l'utilitaire suppose que les services ClientAdapter et DbSync s'exécutent en local et vous invite à spécifier les ports des services ClientAdapter et DbSync.

Le Tableau 6-1 présente les options DIVAnetAdmin, sélectionnables dans un système de menu.

Tableau 6-1 Options DIVAnetAdmin

Catégorie

Option

Description

Synchronisation de la base de données d'actifs

List Synced Sites

Génère la liste des sites dans lesquels les informations d'actif sont en cours de synchronisation. Elle affiche également le statut de synchronisation de chaque site. Si un site est dans un état de synchronisation initiale, le pourcentage de progression est également affiché.

Synchronisation de la base de données d'actifs

Resync a Site

Resynchronise tous les enregistrements d'objet à partir d'un site particulier pour la base de données DIVAnet.

Attention: cette option supprimera tous les enregistrements d'actif dans la base de données DIVAnet (pour le site sélectionné) avant de les resynchroniser.

Synchronisation de la base de données d'actifs

Resync an Object

Met à jour tous les enregistrements d'objet pour un objet donné sur un site spécifique. Ne synchronise pas les suppressions.

Connexions API

List API Connection

Liste toutes les connexions API DIVAnet client, y compris celles en mode direct.

Connexions API

End API Connection

Fournit une option pour mettre fin à une connexion API donnée, identifiée par un ID.

Reload Workflow Profiles

Reload Workflow Profiles

Cette option provoque le rechargement de tous les profils de workflow. Elle recharge également toutes les règles d'accès qui sont définies.

Si des règles d'accès sont définies, cette option requiert un accès à l'opération ChangeConfig.

Paramètres de site

Show Site Parameters

Cette option affiche les paramètres de site DIVA, notamment le nombre de demandes en file d'attente pour le site, le nombre de demandes (envoyées par DIVAnet) s'exécutant sur chaque site, la date de la dernière communication avec le site et les paramètres de limitation.

Paramètres de site

Set Site Parameters

Cette option permet à l'utilisateur de définir les paramètres de limitation DIVA :

- Le paramètre SubmittedThrottleThreshold contrôle le nombre de demandes que DIVA doit envoyer à un site avant d'attendre que l'une d'entre elles se termine.

- Le paramètre TotalThrottleThreshold est similaire mais il est basé sur le nombre total de demandes en cours d'exécution sur le site DIVA. DIVAnet attend jusqu'à ce que le nombre total de demandes DIVA tombe sous cette limite (avant d'envoyer la demande suivante).

Si des règles d'accès sont définies, cette option requiert un accès à l'opération ChangeConfig.

Statistiques d'exécution

Show Runtime Stats: ClientAdapter

Cette option affiche des statistiques d'exécution utiles pour le service ClientAdapter.

Statistiques d'exécution

Show Runtime Stats: DbSync

Cette option affiche des statistiques d'exécution utiles pour le service DbSync.

Niveau de journalisation

Set Log Level: ClientAdapter

Cette option répertorie le niveau de journalisation des services ClientAdapter et permet de le modifier de façon dynamique (les valeurs valides sont ERROR, WARN, INFO, DEBUG, TRACE).

Niveau de journalisation

Set Log Level: DbSync

Cette option répertorie le niveau de journalisation des services DbSync et permet de le modifier de façon dynamique (les valeurs valides sont ERROR, WARN, INFO, DEBUG, TRACE).

DIVAnet crée les types de fichiers journaux suivants :

- Journaux de suivi : situés dans le répertoire de base DIVAnet, dans le sous-dossier Program/log/divanet. Chacun des services DIVAnet (ManagerAdapter, DbSync et ClientAdapter) crée son propre sous-dossier sous le dossier Program/log/divanet et génère ses fichiers journaux dans ce sous-répertoire.

- Journaux de service de wrapper : ces journaux consignent des messages liés au démarrage et à l'arrêt du service Windows. C'est l'emplacement à consulter si le service ne démarre pas correctement. Ces journaux figurent dans le répertoire de base DIVAnet, dans le sous-dossier Program/log/divanet. Ils seront nommés de la même façon que le fichier Wrapper.conf mais avec une extension de nom de fichier .log (par exemple, ManagerAdapterWrapper.log).

- Journaux de GUI : les erreurs survenant dans DIVAnetUI s'afficheront sur l'ordinateur client, pas du côté serveur. Ces journaux figurent dans le sous-dossier Program/log/divanet/gui.

DIVAnet regroupe les journaux âgés de plus d'une heure en fichiers zip et conserve les journaux pendant deux jours pour consultation.

Traitement et mise en file d'attente des demandes

Les sections suivantes traitent de la mise en file d'attente et du traitement des demandes DIVAnet.

Mise en file d'attente de demandes DIVAnet

DIVAnet peut accepter davantage de demandes que les systèmes DIVArchive en aval ne peuvent en traiter en les plaçant dans des files d'attente. DIVAnet applique un nombre maximal de demandes pouvant être mises en file d'attente et (ou) en cours d'exécution en interne (la valeur par défaut est 5000), à l'aide du paramètre GlobalDivanetRequestLimit. DIVAnet commencera à rejeter les demandes si cette limite est atteinte. Le service DIVAnet ClientAdapter gère une file d'attente pour chaque site. Vous pouvez configurer DIVAnet pour alimenter les sites lentement ou pour envoyer toutes les demandes à la fois aux sites (où elles seront probablement mises en file d'attente par DIVArchive).

Si une demande est mise en file d'attente pour un système DIVArchive et que le système DIVA est redémarré, toutes les demandes en cours d'exécution seront arrêtées. DIVAnet se comporte différemment, en stockant chaque demande dans une base de données. Si le service ClientAdapter est redémarré, DIVAnet lit les demandes en attente et en cours d'exécution et les relance. Toutefois, toutes les demandes ne sont pas redémarrées de cette façon. Par exemple, les demandes de suppression ne seront jamais relancées après le redémarrage du service. S'il n'est pas souhaitable de récupérer les demande lors du démarrage, le paramètre ClientAdapter AbortAllOnStartup peut être défini pour mettre fin à toutes les demandes dans la file d'attente au démarrage.

Limitation des demandes DIVAnet

Par défaut, DIVAnet enverra une centaine de demandes à un site avant de s'arrêter et d'attendre que l'une des demandes se termine. Le paramètre qui contrôle la limite est SubmittedThrottleThreshold ; il est configurable dans le service ClientAdapter sur une base par site. Il peut également être modifié au moment de l'exécution via l'utilitaire DIVAnetAdmin. En outre, DIVAnet peut limiter les demandes en fonction du nombre total de demandes en cours d'exécution sur un site DIVArchive (à l'aide du paramètre TotalThrottleThreshold). Vous pouvez définir le paramètre sur -1 pour indiquer qu'aucune limitation ne doit être effectuée. Vous pouvez également régler la valeur sur 0, pour indiquer qu'aucune demande de la file d'attente ne doit être envoyée à DIVArchive. Cela peut être utile dans certains cas.

Si une demande DIVAnet est mise en file d'attente pour un site donné pendant plus de quelques secondes, DIVAnetUI affichera la position de la demande dans la file d'attente. Si une autre demande est mise en file d'attente avec une priorité supérieure à la première, elle aura une position plus élevée dans la file d'attente. Si la demande échoue et est retentée, elle sera de nouveau mise en file d'attente (et aura une accélération de priorité car elle est dans le système depuis plus longtemps).

Nouvelles tentatives de demande DIVAnet

Certaines demandes peuvent faire l'objet de nouvelles tentatives automatiquement dans DIVAnet. Les demandes de copie, de restauration, de restauration de fichiers partielles et de suppression peuvent être retentées. Les demandes de restauration et de restauration de fichiers partielle peuvent être retentées selon un nombre de fois configurable, alors que les demandes de copie et de suppression sont retentées en fonction d'un intervalle de temps configurable. Les nouvelles tentatives peuvent être spécifiées par profil de workflow et peuvent être modifiées au moment de l'exécution sans redémarrage du service ClientAdapter (pour plus d'informations, voir Configuration des profils de workflow).

Si un site est indisponible et que des demandes sont en file d'attente pour ce site, DIVAnet attendra quelques minutes (SiteDownRequeueWaitMins) que le site soit de nouveau opérationnel. Si cette période s'écoule et que de nouvelles tentatives sont configurées, DIVAnet tentera de relancer la demande, éventuellement sur un autre site. Si les nouvelles tentatives ne sont pas configurées, la demande prendra fin.

7 Prise en charge d'API

Ce chapitre décrit la prise en charge de l'API DIVArchive de DIVAnet et fournit des informations sur la spécification d'informations propres à DIVAnet à l'aide de l'API DIVArchive. Il est destiné à être utilisé avec la documentation de l'API DIVArchive C++, de l'API DIVArchive Java, ou de l'API DIVArchive Web Service.

- Compatibilité de version d'API DIVAnet

- Opérations sur du contenu archivé

- Autres commandes prises en charge

- Demandes non prises en charge

- Codes de retour

Compatibilité de version d'API DIVAnet

DIVAnet prend en charge un sous-ensemble du jeu complet de commandes de l'API DIVArchive. Certaines commandes de l'API DIVArchive (telles que EjectTape) seront rejetées dans le mode MultiDiva de DIVAnet. DIVAnet 2.1 prend en charge les connexions des clients de l'API DIVArchive des versions 7.3 et antérieures. Toute nouvelle fonctionnalité ajoutée à l'API après la version 7.3 ne sera pas prise en charge par DIVAnet 2.1.

Les appels d'API DIVA sur un serveur DIVAnet sont très similaires aux appels sur DIVArchive. Il y a toutefois quelques différences. DIVAnet accepte parfois les paramètres connus de l'API DIVA de façon légèrement différente. En outre, le contenu des champs renvoyé par DIVAnet peut être légèrement différent de DIVArchive, ou avoir un autre format. Cette section décrit ces différences.

DIVAnet 2.1 requiert que les sites DIVArchive connectés soient installés avec DIVArchive 7.3.1 ou une version ultérieure. Il est ensuite possible de mettre à niveau les sites DIVArchive sans procéder à la mise à niveau de DIVAnet.

Opérations sur du contenu archivé

Cette section décrit les demandes qui impliquent le transfert (ou la suppression) de contenu archivé, notamment les demandes d'archivage, de restauration, de suppression et de copie. Ces commandes peuvent être appelées au moyen de l'API DIVArchive. Certaines peuvent l'être à partir de DIVAnetUI. Reportez-vous à la documentation Oracle DIVArchive C++ API Reference Manual pour plus d'informations concernant l'action de chaque commande dans l'API DIVArchive.

Remarque :
En mode MultiDiva, les demandes DIVAnet nécessitent souvent des informations que les demandes émises directement vers DIVArchive ne requièrent pas.

Les demandes DIVAnet requièrent souvent des informations supplémentaires à cause de la fonctionnalité prise en charge. Par exemple, vous pouvez utiliser la commande Copy dans DIVAnet pour copier du contenu d'un système DIVA vers un autre. DIVAnet doit savoir, au minimum, quel est le site cible. Cependant, la commande de l'API DIVA CopyToGroup ne contient pas de paramètre de site cible (target site). Les sections ci-après décrivent comment indiquer ces informations supplémentaires. Pour plus d'informations sur la configuration du mode MultiDiva de DIVAnet, voir Configuration des ports API client.

Le Tableau 7-1 identifie les demandes de contenu de l'API DIVArchive qui sont prises en charge par DIVAnet. Les clients qui émettent ces demandes reçoivent un ID de demande en retour, qui permet l'interrogation périodique du statut de la demande.

Tableau 7-1 Demandes de contenu DIVArchive prises en charge

Demande

Comportement dans DIVAnet

Archive

Archivage sur le site DIVArchive local ou, éventuellement sur un autre site sélectionné.

Pour plus d'informations, voir Demandes d'archivage.

Restore

Restore Instance

Restaurer un objet archivé vers une source/destination spécifique. Une instance spécifique et (ou) un site donné peut être utilisé comme contenu source pour la restauration.

DIVAnet détermine s'il faut (1) restaurer un objet à partir du DIVArchive local, (2) restaurer directement un objet à l'aide d'un DIVArchive distant, ou (3) extraire un objet à partir du DIVArchive distant puis le transférer vers la source/destination choisie.

Une commande Restore Instance permet de restaurer une instance spécifique sur un site donné. En cas d'échec, vous pouvez configurer DIVAnet pour de nouvelles tentatives sur d'autres sites.

Pour plus d'informations, voir Demandes de restauration.

Partial Restore

Partial Restore Instance

Restauration partielle d'un objet, similaire à une restauration complète. Une instance (sur un site donné) peut être utilisée comme source pour la restauration de fichiers partielle.

En cas d'exécution d'une restauration de fichiers partielle sur un système distant, ce site DIVA doit être configuré pour une restauration partielle similaire pour le site local.

Pour plus d'informations, voir Demandes de restauration de fichiers partielle.

Copy (CopyToGroup)

Copier du contenu d'un site DIVA vers un autre (copie intersite), ou créer une autre instance d'un objet sur un site DIVA (équivaut à exécuter une commande CopyToGroup sur un seul système DIVA).

Une instance spécifique peut être copiée sur un site cible. Le message CopyToNew n'est pas pris en charge. Vous pouvez configurer DIVAnet pour de nouvelles tentatives pendant une période donnée.

Pour plus d'informations, voir Demandes de copie.

Delete

DeleteInstance

Supprimer du contenu de tous les sites, d'un site spécifique, ou supprimer une instance spécifique d'un site donné. Si des objets sont verrouillés sur les sites à supprimer, vous pouvez configurer DIVAnet pour de nouvelles tentatives pendant une période donnée.

Pour plus d'informations, voir Demandes de suppression.

Demandes d'archivage

Une demande d'archivage permet à l'appelant d'archiver du contenu qui existe sur une source/destination donnée (configurée dans DIVArchive). L'API DIVA organise un transfert à partir de la source/destination vers DIVArchive. Ceci diffère d'une API cloud basée sur Web où le contenu est transféré directement du demandeur via HTTPS. Par défaut, DIVAnet effectue l'archivage sur le site local.

Les demandes d'archivage envoyées à DIVAnet sont similaires à celles envoyées directement à DIVArchive, avec toutefois quelques ajouts au paramètre Target Sitename (site DIVArchive où le contenu sera archivé). En général, DIVAnet effectue l'archivage sur le site local. Cependant, il est possible d'effectuer l'archivage directement sur un autre site, de l'une des deux façons suivantes :

- En indiquant l'option -site [sitename] dans le champ d'options. Par exemple : -site diva1.

- En ajoutant au paramètre de média un préfixe indiquant un nom de site de destination dans la demande d'archivage. Par exemple, sitename1_TapeGroup1 indique un site de destination appelé sitename1 et un média TapeGroup1.

DIVAnet ne prend pas en charge les nouvelles tentatives continues pour des commandes Archive, mais prend en charge une option BackupArchiveSite qui fournit un site d'archivage de secours en cas d'indisponibilité du site principal.

Demandes de restauration

Une demande de restauration permet au client de restaurer du contenu qui existe dans le système d'archivage. Le contenu arrive sur la source/destination sélectionnée dans la demande. L'API DIVA organise un transfert à partir d'un site DIVArchive directement vers une source/destination (telle qu'un disque FTP ou CIFS). Ce comportement diffère de celui d'une API cloud basée sur le Web, où le contenu est transféré directement vers le demandeur via HTTPS.

Lors de la restauration de contenu à l'aide de DIVAnet, l'appelant doit savoir quel système DIVA détient le contenu. En outre, en cas d'échec lors de la récupération du contenu à partir d'un site DIVA, un autre site DIVA peut automatiquement être consulté pour extraire ce contenu.

DIVAnet prend en charge la restauration vers une source/destination quelconque sur tout site DIVANET. DIVAnet extrait le contenu d'autres sites, si nécessaire, pour satisfaire la demande, avant de transférer le contenu vers la source/destination cible.

Les demandes de restauration envoyées à DIVAnet sont semblables à celles envoyées directement à DIVArchive, à quelques ajouts près. En principe, DIVAnet choisit le site à partir duquel effectuer la copie. DIVAnet permet toutefois à un client de préciser le site à utiliser pour la restauration. Il existe plusieurs méthodes :

- -site : normalement, DIVAnet choisit le site à partir duquel effectuer la restauration. Cependant, vous pouvez tenter une restauration à partir d'un site donné en indiquant l'option -site [sitename] dans le champ d'options de la demande. Si le contenu ne se trouve effectivement pas sur le site choisi, l'opération échoue.

- Instance Id : si vous avez besoin d'un contrôle complet sur la source, vous pouvez indiquer un numéro d'instance dans la demande de restauration. Cela vous permettra de choisir le site source et l'instance DIVA à partir de laquelle effectuer la restauration (voir la section suivante). Cette identification d'instance peut être obtenue à l'aide d'un appel d'API getObjectInfo() ou en affichant l'objet dans DIVAnet UI.

Dans ces deux cas, les nouvelles tentatives sont désactivées.

Workflow de restauration

Pour satisfaire une demande de restauration, DIVAnet utilise les méthodes de restauration décrites dans le Tableau 7-2. DIVAnet sélectionne de façon dynamique le workflow de restauration à utiliser en fonction de paramètres tels que la source/destination cible et l'objet source. Pour déterminer les sites à utiliser pour les restaurations, DIVAnet pose une série de questions, notamment :

- L'objet est-il disponible sur le système DIVArchive local ?

- L'objet comporte-t-il une instance de disque ?

- La source/destination est-elle accessible à partir du système DIVArchive distant ?

- La source/destination est-elle accessible à partir du site local ?

- DIVArchive est-elle en cours d'exécution sur les sites source ou cible ?

- Un site est-il privilégié par rapport à un autre dans le fichier de configuration ?

Tableau 7-2 Méthodes de restauration DIVAnet

Méthode

Description

Locale

Utilisée quand un objet existe sur le site local. Le site local est le nom de site du système DIVArchive auquel vous envoyez des messages. Un système DIVArchive local est également considéré comme partie du site local.

Distante directe

DIVAnet peut faire en sorte qu'un système DIVA distant effectue une opération de restauration. Ceci n'arrive que si la source/destination cible est également configurée dans le système DIVA distant. Les noms de source/destination doivent correspondre et doivent tous les deux faire référence au même serveur ou disque (et au chemin sur ce disque, le cas échéant).

Si elle est disponible, DIVAnet préfère utiliser cette méthode plutôt que d'exécuter une restauration à l'aide de la copie intersite.

Utilisation de la copie intersite

Si le contenu n'est pas local, et si un système DIVA distant ne peut pas effectuer une restauration directe vers la source/destination cible, DIVAnet peut faire en sorte que le contenu soit livré en deux étapes.

Tout d'abord, le site DIVA distant effectue la restauration vers une source/destination partagée entre les sites source et cible. Puis le site DIVA local archive l'objet et effectue finalement la restauration vers la source/destination cible. Ainsi, les demandes futures de ce contenu seront extraites beaucoup plus rapidement.

Si vous souhaitez effectuer systématiquement des restaurations distantes en créant une copie de proximité, définissez AllowDirectRemoteRestores sur false dans le profil de workflow.

Utilisation du transfert intersite

Dans certains cas, quand DIVAnet n'est pas en mesure d'effectuer une restauration distante directe, DIVAnet livre le contenu en deux étapes (restauration à l'aide de la copie intersite) mais n'archive pas réellement le contenu en local. Un de ces cas implique la fonction Oracle Partial File Restore.

Tout d'abord, DIVAnet indique au DIVA source de transférer le contenu vers la source/destination accessible à la fois par les sites DIVA source et cible. Ensuite, le site DIVA local transfère le contenu vers la source/destination cible sans l'archiver.

Sources et destinations

DIVAnet vous permettra d'effectuer la restauration sur une source/destination disponible sur un site quelconque. DIVAnet suppose que si une source/destination existe avec le même nom sur deux sites, les deux configurations pointent vers le même Server\Device\Path physique. Les utilisateurs doivent faire preuve de circonspection envers les noms affectés aux sources/destinations à travers les différents sites.

Si un système DIVA distant ne peut pas effectuer une restauration directe sur une source/destination cible, DIVAnet peut faire en sorte que le contenu soit livré en deux étapes (voir la section sur la restauration à l'aide du transfert intersite). DIVAnet ne procède ainsi que si la source/destination est le site préféré pour la source/destination considérée (voir Mappages source/destination préférés).

Nouvelles tentatives

Vous pouvez configurer la commande Restore pour effectuer de nouvelles tentatives plusieurs fois en cas d'échec de la première restauration. Si le contenu à restaurer existe sur plusieurs sites, DIVAnet tentera automatiquement la restauration avec ces sites. Vous pouvez configurer le nombre maximal de nouvelles tentatives. Dans certains cas, DIVAnet décidera de refaire une tentative avec le même site avant de passer à d'autres. Le cas échéant, DIVAnet examinera la valeur RestoreRetryIntervalMins pour déterminer le délai d'attente avant d'effectuer une nouvelle tentative avec le même site.

Restrictions

- DIVAnet 2.1 prend en charge un sous-ensemble de l'API DIVArchive. Pour obtenir une liste des messages pris en charge, reportez-vous au chapitre correspondant.

- DIVAnet 2.1 offre une prise en charge restreinte pour les restaurations multiples. DIVAnet n'autorise pas les restaurations multiples pour des sources/destinations distantes, et ne permet ni la consultation ni la surveillance de plusieurs sources/destinations au moyen de l'interface utilisateur. Il est possible d'utiliser la restauration multiple si l'objet existe localement mais est inaccessible (par exemple, il a été externalisé localement).

- DIVAnet 2.1 ne prend pas en charge les relations de site P2P, y compris l'équilibrage de la charge.

Demandes de restauration de fichiers partielle

Outre les restaurations complètes de contenu, DIVAnet prend en charge les restaurations de fichiers partielles. DIVAnet détermine le site où le contenu est situé et permet d'en restaurer une partie.

Si un objet existe sur un système DIVA distant, et que la source/destination cible de la restauration n'est pas accessible par un système DIVA distant, DIVAnet transfère le contenu en deux étapes : tout d'abord en utilisant le site DIVA distant afin d'obtenir le contenu sur le site DIVA local (sans transférer l'objet entier), puis en utilisant le site DIVA local pour restaurer le contenu vers la source/destination cible.

Comme pour la restauration, vous pouvez indiquer le numéro d'instance ou le paramètre -site pour effectuer une restauration à partir d'un site spécifique, ou spécifier de nouvelles tentatives en cas d'échec du site initial. De même, la restauration vers des destinations multiples dans une même demande de restauration n'est pas prise en charge.

Demandes de copie

Une demande de copie crée une nouvelle instance de contenu archivé à partir d'une instance existante. DIVAnet permet de copier du contenu d'un site DIVA vers un autre. La commande d'API DIVArchive CopyToGroup (1) copie un objet d'un site DIVA vers un autre, ou (2) crée simplement une nouvelle instance sur un seul site. Pour des copies, DIVAnet doit dériver certains paramètres qui ne sont pas disponibles dans l'API DIVA. Le Tableau 7-3 décrit ces paramètres.

Tableau 7-3 Paramètres dérivés de copie DIVAnet

Attribut dérivé

Description

Target Sitename

Indique le site vers lequel l'objet doit être copié.

Le nom de site cible n'existe pas en tant que champ architecturé dans l'API DIVA. Vous pouvez l'indiquer pour DIVAnet de deux façons :

- Option -site : en indiquant l'option -site [sitename] dans le champ d'options. Un exemple serait -site sitename1.

- Préfixe de média de nom de site : en préfixant un nom de site de destination pour le paramètre de média dans une demande de copie (avec un trait de soulignement (_) séparant les deux champs). Par exemple, sitename1_TapeGroup1 indique un site de destination de copie appelé sitename1, et un média de TapeGroup1.

Si vous ne spécifiez aucun nom de site, le site local est supposé. Le mot-clé -site ne fonctionnera qu'avec une API version 7.3 ou supérieure.

Media

Media indique le type de média à utiliser pour stocker l'objet copié. DIVAnet permet également d'indiquer un plan de stockage DIVA comme nom de média. Storage Plan fonctionnera uniquement si la copie est une copie intersite.

Vous pouvez préfixer le nom de site cible pour le média pour indiquer aussi le nom de site cible.

Si vous ne savez pas quel média indiquer, vous pouvez spécifier un média ayant la valeur any pour laisser le système choisir le média sur lequel effectue le stockage sur le site cible. Par exemple, un média diva1_any copie vers le site diva1, mais DIVAnet choisit le média. La valeur par défaut que fournit DIVAnet peut ne pas convenir pour certains cas d'utilisation.

Si l'objet est déjà sur le site cible et que la valeur any est spécifiée, le système renverra simplement un message de succès.

Source Sitename
(Instance Id)

En général, DIVAnet choisit le site à partir duquel effectuer la copie. Toutefois, si vous avez besoin d'un contrôle complet sur la source, vous pouvez indiquer un numéro d'instance dans la demande de copie. Ceci vous permet de choisir le site source, de façon implicite, et l'instance DIVA à partir de laquelle effectuer la copie (voir la section suivante). Vous pouvez obtenir cet ID en exécutant un appel d'API getObjectInfo() sur l'objet à copier.

Méthodes de transfert de site à site

Dans une demande de copie DIVAnet, si le site source est le même que le site cible, DIVAnet peut simplement émettre une commande CopyToGroup au site DIVA cible. Pour des copies intersite, DIVAnet permet de configurer la méthode utilisée pour effectuer ces copies. Pour chaque paire de noms de site source et cible (par exemple, site1 vers site2), le Tableau 7-4 répertorie les méthodes de transfert disponibles.

Outre la méthode de copie, chaque paire de noms de site source et cible contient la source/destination utilisée pour la zone de stockage commune. Le média de destination par défaut (pour RestoreAndArchive), les paramètres d'option (transmis à DIVArchive) et d'autres paramètres sont également configurables.

Tableau 7-4 Méthodes de copie de site à site

Type

Description

RestoreAndArchive

Avec cette option, DIVAnet restaure le contenu du site source vers une source/destination commune aux sites cible et source. Puis DIVAnet indique au système DIVArchive cible d'archiver le contenu désormais situé dans la zone de stockage commune. Il s'agit d'une alternative à l'utilisation des dossiers de dépôt.

RestoreAndMonitor

Avec cette méthode, DIVAnet effectue la copie en restaurant d'abord le contenu vers une destination spécifique. DIVAnet passe ensuite à la surveillance du système DIVArchive cible pour déterminer quand le contenu est archivé avec succès sur le site cible. La demande est satisfaite uniquement lorsque le contenu est archivé avec succès sur le site cible.

Cela suppose évidement un autre processus ou programme qui prend le contenu et l'archive dans le système DIVA cible. Cette option s'avère utile en combinaison avec le logiciel DIVArchive Drop Folder Monitor (DFM). Chaque dossier DFM est configuré pour l'archivage à l'aide d'un média présélectionné, ce qui signifie que quand DFM est utilisé pour des copies, le paramètre de média est ignoré.

Restore

Avec cette méthode, DIVAnet effectue la copie en restaurant vers une destination spécifique, puis en renvoyant un message de succès. Cette méthode ne confirme pas que le contenu a été archivé avec succès sur le site cible et risque de provoquer des échecs en cas de tentatives de workflows de restauration copie intersite.

La commande Copy de DIVAnet renverra un message de succès si une instance de l'objet existe déjà dans le site cible sur le média demandé. Dans ce cas, DIVArchive mettra fin à la demande.

Copies locales

En cas de demande de copie d'un objet vers un site où cet objet existe déjà mais ne présente pas le média demandé, DIVAnet crée une autre instance de l'objet sur ce site en utilisant le média spécifié dans la demande. Il existe une exception à ce comportement si la valeur any est indiquée en tant que média. Dans ce cas, DIVAnet ne crée pas d'autre instance.

Sélection par DIVAnet (média avec la valeur any)

Dans DIVAnetUI, une option permet à DIVAnet d'affecter le média cible sur une opération de copie (utilisation d'un média Selected By DIVAnet). Vous pouvez parvenir au même résultat dans une demande d'API DIVA en indiquant un média de valeur any dans la demande de copie. DIVAnet utilisera sa configuration pour déterminer le média à utiliser pour la copie (voir Mappages de site à site pour plus d'informations).

Si la valeur any est transmise et que l'objet existe déjà sur le site cible, DIVAnet ne créera pas d'autre instance de l'objet. Aucune action supplémentaire ne sera effectuée et la demande aboutira.

Nouvelles tentatives

DIVAnet prend également en charge de nouvelles tentatives périodiques sur des copies. Si cette option est activée dans le profil de workflow, DIVAnet retente les opérations de copie qui ont échoué. Dans le profil de workflow, vous pouvez configurer la fréquence de renouvellement des demandes ainsi que le délai d'attente entre les nouvelles tentatives. Pour plus d'informations, voir Configuration des profils de workflow.

Demandes de suppression

Une demande de suppression DIVArchive permet à l'appelant de retirer un objet archivé. Une demande de suppression DIVAnet, par défaut, supprimera l'objet de tous les sites DIVArchive. Une demande de suppression d'instance (DeleteInstance) DIVAnet peut supprimer une ou plusieurs instances d'un seul site DIVA. En réalité, DIVAnet peut donc effectuer trois types de suppression. Le Tableau 7-5 décrit les types de suppression et les paramètres qu'ils requièrent.

Tableau 7-5 Types de suppression

Type

Attributs dérivés

Description

Global Delete

NA

Supprime toutes les instances de l'objet sur tous les sites.

Dans l'API, l'absence de spécification de média ou d'ID d'instance dans la demande provoque la suppression de l'objet spécifié de tous les sites.

Instance Delete

Target Sitename

Supprime une seule instance d'objet sur un site donné.

Dans l'API, spécifiez un ID d'instance ou un média pour supprimer une instance d'objet spécifique d'un site donné.

Si vous spécifiez un ID d'instance, vous ciblez une instance spécifique sur un site donné. La transmission des paramètres de média ou d'options n'est pas nécessaire.

Si vous indiquez un média, DIVAnet doit connaître le site à partir duquel vous voulez effectuer la suppression. Vous pouvez spécifier le site de trois façons :

- Préfixe de nom de site de média : vous pouvez préfixer le nom de site pour le média. Par exemple, siteA_tapeGroup1 indique à DIVAnet de supprimer l'instance sur le siteA ayant un média de tapeGroup1. Si vous n'indiquez pas de nom de site, le site local est supposé.

- Option -site : spécifiez l'option -site [sitename] dans le champ d'options, et indiquez un média. Cette option est prise en charge dans DIVArchive API 7.3 et supérieure.

- Média (sans aucun site) : vous indiquez le média sans site. Dans ce cas, le site local est supposé.

Site Delete

Target Sitename

Supprime toutes les instances d'un objet sur un site donné. Vous pouvez le faire de trois façons :

- Utiliser DIVAnetUI : vous pouvez supprimer toutes les instances sur un site donné en exécutant la commande Delete à partir de DIVAnetUI.

- Nom de site/média ayant la valeur any : exécutez une commande DeleteInstance via l'API en indiquant le nom de site et un média avec la valeur any dans le champ de média (par exemple, siteA_any).

- Option -site : fournissez un nom de site en indiquant l'option -site [sitename] dans le champ d'options. Cette option est prise en charge dans DIVArchive API 7.3 et supérieure.

Suppression de site (média avec valeur any)

Comme indiqué dans le tableau précédent, si un nom de site est fourni et qu'un média a la valeur any, toutes les instances de l'objet seront supprimées du site sélectionné. Vous pouvez également indiquer l'option -site [sitename] dans le champ d'options.

Dernière instance

DIVAnet n'autorisera pas l'aboutissement d'une commande Instance Delete lors d'une tentative de suppression de la dernière instance d'un objet archivé (à savoir, la dernière instance qui existe dans la base de données DIVAnet). Dans ce cas, une commande Global Delete ou Site Delete devra être émise. Notez cependant qu'une commande Site Delete autorisera la suppression de la ou des dernières instances. Vous pouvez utiliser des règles d'accès pour prévenir des commandes Instance Delete ou Site Delete qui sont effectivement des demandes Global Delete (voir Configuration des règles d'accès pour plus d'informations).

Par ailleurs, si un utilisateur envoie une demande de suppression directement à DIVArchive, il peut exister une période pendant laquelle DIVAnet ne peut pas assurer la protection de la dernière instance.

Nouvelles tentatives et annulations

Si une commande Delete est reçue par DIVAnet, et que DIVAnet est en cours d'exécution d'une copie intersite de l'objet, la demande DIVAnet qui a déclenché la copie sera annulée. La copie peut être le résultat d'une commande Copy ou d'une commande Restore qui effectue une copie pour satisfaire la restauration. D'autres types de demandes DIVAnet ne seront pas annulées.

Si une demande DIVArchive st en cours d'exécution pour le compte d'une demande DIVAnet, DIVArchive verrouille l'objet pour empêcher sa suppression. Ainsi, si un objet est verrouillé avant que DIVAnet puisse envoyer un message de suppression à DIVArchive, la demande de suppression échoue.

DIVAnet prend en charge de nouvelles tentatives périodiques de suppression en cas d'échec de suppression. Si cette option est activée dans le profil de workflow, DIVAnet essaiera d'effectuer des suppressions sur des sites où (par exemple) des instances/objets à supprimer sont verrouillés. Vous pouvez configurer la fréquence des nouvelles tentatives dans DIVAnet.

Autres commandes prises en charge

Le tableau Tableau 7-6 identifie les commandes d'API DIVArchive qui ne sont pas liées à du contenu. Ces commandes obtiennent des informations sur les objets et les demandes et aucun ID de demande ne leur est assigné.

Tableau 7-6 Autres commandes DIVArchive non liées à du contenu prises en charge

Demande

Description

Comportement dans DIVAnet

Cancel

Annuler une demande DIVAnet.

L'option -site ne s'applique pas à cette commande.

GetObjectInfo

Utiliser la base de données DIVAnet pour obtenir des informations sur un objet archivé.

DIVAnet renvoie toutes les instances de l'objet sur tous les sites DIVAnet. Vous indiquez le nom et la catégorie de l'objet (Object Name et Object Category) (vous pouvez ne pas renseigner la catégorie mais si plusieurs objets ont le même nom, l'appel échouera). DIVAnet utilise la base de données DIVAnet pour renvoyer des informations sur l'objet archivé.

Dans la réponse GetObjectInfo(), DIVAnet ajoute au début le nom du site au paramètre de média de chaque instance d'un objet.

L'option -site n'est pas prise en charge pour cette commande.

GetRequestInfo

Extraire des informations concernant une demande DIVAnet à partir de la base de données DIVAnet.

Remarque : Le paramètre Additional Information présente des limites. Les informations supplémentaires sont fournies par DIVArchive et représente des informations provenant de la dernière demande DIVA traitée. Les informations ne reflètent pas les autres sites dans le réseau DIVAnet.

Quand DIVAnet reçoit un appel GetRequestInfo(), il fournit des informations sur les demandes DIVAnet, pas sur les demandes DIVArchive (bien que les demandes DIVAnet impliquent souvent l'appel d'une ou de plusieurs demandes DIVArchive).

L'option -site ne s'applique pas à cette commande.

GetFilesAndFolders

Extraire des informations directement à partir de DIVArchive concernant les fichiers et dossiers figurant dans un objet archivé donné.

Accepte l'option -site pour interroger un site donné ou aucun site pour laisser DIVAnet choisir (option recommandée).

GetObjectDetailsList

Extraire des informations à partir de DIVArchive concernant les objets et les événements d'objet. DIVAnet extrait les informations d'objet directement à partir de chaque système DIVArchive, un site à la fois, à tour de rôle, un batch par site.

Chaque batch contient des informations provenant d'un site DIVA. Si le même objet existe sur deux sites, vous recevrez l'objet deux fois (une fois pour chaque site), une fois dans chaque batch.

Remarque : l'ordre des entrées renvoyées n'est pas garanti. Si un site DIVA est indisponible, GetObjectDetailsList() renverra une erreur et le traitement de la commande s'arrêtera.

Vous pouvez extraire des informations d'un site en préfixant le nom du site pour le champ de média séparé par un trait de soulignement (_). Si vous ne voulez pas que le média soit interrogé, mais que vous voulez extraire des informations d'un site, il vous suffit d'indiquer le nom du site dans le champ de média. Cette commande n'accepte pas l'option -site.

GetObjectsList

Interroge la base de données DIVAnet pour obtenir une liste des catégories et noms d'objet (InitObjectList, CloseObjectList).

La prise en charge de cette commande est limitée dans DIVAnet. Les interrogations des informations de bande ne sont pas prises en charge ; en outre, il existe des limites concernant le nombre d'interrogations simultanées. L'option -site n'est pas prise en charge.

GetArrayList

Renvoie une liste des noms de baie à partir de tous les sites incluant les disques qui composent chaque baie, avec la capacité de disque actuelle.

Le paramètre -site transmis dans le champ des options, peut renvoyer des informations pour un site spécifique.

GetGroupsList

Renvoie une liste des noms de groupe de bandes à partir de tous les sites. Le nom du site est préfixé pour le nom de groupe.

Remarque : Cette commande ne comporte pas de champ d'options. En conséquence, l'option -site n'est pas prise en charge.

GetSourceDestinationList

Renvoie une liste des informations de source et de destination à partir de tous les sites.

Dans la liste renvoyée, le nom de site de la source ou de la destination est préfixé pour le nom de la source ou de la destination, séparé par un trait de soulignement (_).

Le paramètre -site transmis dans le champ des options, peut renvoyer des informations pour un site spécifique.

GetArchiveSystemInfo

Extrait le statut d'un site DIVArchive unique (par défaut, le site local est renvoyé). Elle ne renvoie pas une vue globale de tous les sites.

Le paramètre -site transmis dans le champ des options sélectionne le site à partir duquel les informations sont collectées. Par exemple, -site diva1 routera la demande GetArchiveSystemInfo vers le Manager désigné par le nom de site diva1 et renverra les informations de système d'archivage pour diva1 uniquement.

GetStoragePlanList

Extrait la liste des plans de stockage qui sont définis dans tous les sites DIVArchive configurés.

Dans la liste renvoyée, le nom du plan de stockage présente en préfixe le nom du site du plan de stockage, avec un trait de soulignement (_) comme séparateur.

Le paramètre -site, passwd dans le champ d'options, renvoie des informations concernant un site spécifique.

Demandes non prises en charge

Pour des raisons de compatibilité d'application, ces commandes renverront toujours un message de succès, même si DIVAnet n'effectue aucune action pour les satisfaire.

- Modification de priorité

- Verrouillage d'objet

- Déverrouillage d'objet

- Liaison d'objets

- Demande d'instance

- Libération d'instance

Codes de retour

DIVAnet renvoie des codes de statut qui sont similaires à ce que DIVArchive renvoie. Toutefois, DIVAnet acceptera parfois des demandes que DIVArchive mettrait automatiquement en échec, car souvent DIVAnet ne dispose des informations nécessaires pour effectuer la vérification que très tard lors du traitement de la demande.

En outre, DIVAnet renverra le statut ACCESS_DENIED pour de nombreuses commandes. Ce statut n'est pas renvoyé par DIVArchive. DIVAnet rejettera les demandes qui ne passent pas les vérifications des règles d'accès et rejettera les messages non configurés dans le profil de workflow. Pour des raisons de compatibilité, l'API version 5.8 et antérieure renvoie le statut INVALID_PARAMETER au lieu du statut ACCESS_DENIED.

8 Dépannage

Les erreurs suivantes peuvent survenir dans une installation DIVAnet. Par exemple, bien que les noms de balise dans les fichiers de configuration ne soient pas sensibles à la casse, les valeurs le sont (par exemple, les noms de site), et peuvent provoquer des erreurs.

- Erreurs courantes DIVAnet

- Erreurs courantes DIVAnetUI

Tableau 8-1 Erreurs courantes DIVAnet

Problème

Résolution possible

Un service DIVAnet ne démarre pas

- Lors de l'installation d'un service, veillez à transmettre le nom du fichier wrapper.conf de l'adaptateur et non le nom du fichier de configuration de l'adaptateur.

- Assurez-vous de placer le fichier de configuration dans le répertoire parent du dossier des modèles et de supprimer l'extension .ini.

- Si des erreurs se produisent lors de la lecture du fichier de configuration, elles s'afficheront dans les journaux du wrapper. Ces journaux figurent dans le répertoire de base DIVAnet, dans le dossier Program/log/divanet ; ils seront nommés de la même façon que le fichier Wrapper.conf, mais avec une extension .log.

- Vous devez exécuter le script addSites avant d'essayer de démarrer le service ClientAdapter ou DbSync.

- Les noms de site sont-ils cohérents entre la base de données et les fichiers de configuration ? Si tel n'est pas le cas, les services peuvent ne pas démarrer et (ou) ne pas fonctionner correctement.

Un refus d'accès est renvoyé pour une demande DIVAnet

- Assurez-vous que le profil de workflow correct est configuré pour le port sur lequel vous vous connectez. Assurez-vous que la demande est autorisée dans la section de liste des messages valides du profil de workflow.

- Si vous utilisez des règles d'accès, assurez-vous que ApiConnect figure dans une règle d'inclusion. Si vous utilisez DIVAnetUI, assurez-vous que WebConnect s'affiche.

Les opérations de copie intersite échouent avec des erreurs se rapportant aux noms de source et de destination contenant MISSING_MAPPING_TO

- Assurez-vous que le profil de workflow attendu est bien affecté à la demande en vérifiant la configuration.

- La source ou la destination peuvent être absentes dans la configuration du transfert de site à site de ClientAdapter.

Aucune demande n'a été envoyée avec succès à un site DIVA, bien qu'elles puissent être consultées dans DIVAnet

- Assurez-vous que le paramètre localSitename dans les fichiers de configuration ManagerAdapter reflète correctement le site qu'ils servent (et n'a pas été coupé-collé à partir d'un autre emplacement). Vérifiez que le paramètre localSitename est correct dans les configurations de ClientAdapter et DbSync. Vérifiez que les noms de site sont cohérents avec ceux définis dans la base de données DIVAnet.

- Vérifiez que le port et l'adresse réseau du Manager DIVA auquel vous voulez envoyer des demandes est correct dans la configuration de ClientAdapter.

Dans les règles d'accès, après la définition d'une règle Exclude, l'opération est rejetée dans tous les cas.

- Gardez à l'esprit que pour qu'une opération aboutisse, il doit exister une règle Include pour l'opération en question.

- Faites attention aux paramètres définis par défaut dans le Ruleset, notamment WorkflowProfile ; modifiez-les au besoin.

Tableau 8-2 Erreurs courantes DIVAnetUI

Problème

Résolution possible

Impossible de se connecter à DIVAnet

- Assurez-vous que vous avez indiqué l'URL correcte pour DIVAnet. Par défaut, il s'agit de l'adresse de l'ordinateur sur lequel s'exécute le service ClientAdapter, sur le port défini dans le paramètre WebServicePort de la configuration ClientAdapter.

- Veillez à indiquer le port dans l'URL (le cas échéant), et spécifiez https si des connexions sécurisées sont activées.

L'interface utilisateur ne met plus à jour la progression des demandes existantes et n'affiche plus les nouvelles demandes.

- Pour déterminer si une erreur de connexion s'est produite, vérifiez l'angle inférieur droit de l'interface graphique (GUI) DIVAnet. Si tel est le cas, cliquez sur les boutons Requests ou Assets pour afficher de nouveau la boîte de dialogue de connexion.

- Il est possible que vous ayez indiqué une heure de fin dans votre demande. Cela indique à DIVAnetUI que les mises à jour live ne doivent pas être affichées et que la progression des demandes en cours ne doit pas être mise à jour. Pour activer les mises à jour live, il vous suffit de supprimer le filtre d'heure de fin.

- Enfin, vérifiez le panneau Request Filters pour vous assurer qu'il n'y ait pas de filtres de type de demande ou de statut de demande activés (idem pour les heures de début et de fin).

Les objets récemment archivés ne s'affichent pas dans la vue des actifs

- Vérifiez que le service DbSync est en cours d'exécution. Vérifiez la configuration pour vous assurer que les adresses réseau sont correctes. Vous devrez peut-être vous assurer que le service ManagerAdapter sur le site en cours de synchronisation est configuré et en cours d'exécution.

- Si la configuration est correcte et que le problème persiste, il est conseillé de lancer une resynchronisation de ce site au moyen de l'utilitaire d'administration de DIVAnet.

Un accès refusé est renvoyé pour une opération de copie, de suppression ou d'annulation dans l'interface utilisateur

- Assurez-vous que le profil de workflow correct est configuré dans le WebDefaultWorkflowProfile du service ClientAdapter. Assurez-vous que la demande est autorisée dans la section de liste des messages valides du profil de workflow.

- Si vous utilisez des règles d'accès, assurez-vous que WebConnect figure dans une règle d'inclusion.

A Exemples de fichier de configuration

- Exemple de configuration ClientAdapter

- Exemple de configuration ManagerAdapter

- Exemple de configuration DbSync

Exemple de configuration ClientAdapter

<config>
<!-- TOP-LEVEL -->
<LocalSiteName>diva1</LocalSiteName>
<LogLevel>INFO</LogLevel>
<MaxClientConnections>50</MaxClientConnections>
<WebServicePort>9801</WebManagementPort>

<!-- ADAPTER PORTS -->
<AdapterPorts>
<AdapterPort>
<ListenPort>7100</ListenPort>
<RoutingType>Direct</RoutingType>
<Sitename>diva1</Sitename>
</AdapterPort>
<AdapterPort>
<ListenPort>7101</ListenPort>
<RoutingType>MultiDiva</RoutingType>
<WorkflowProfile>default</WorkflowProfile>
</AdapterPort>
</AdapterPorts>

<!-- DIVA MANAGERS -->
<DivaManagers>
<DivaManager>
<Address>127.0.0.1</Address>
<Port>9000</Port>
<Sitename>diva1</Sitename>
</DivaManager>
<DivaManager>
<Address>172.16.3.59</Address>
<Port>9001</Port>
<Sitename>diva2</Sitename>
</DivaManager>
</DivaManagers>

<!-- DIVAnet DATABASE -->
<DivanetDatabase>
<Address>127.0.0.1</Address>
<Port>1521</Port>
<User></User>
<Password></Password>
</DivanetDatabase>

<!-- WORKFLOW PROFILES -->
<WorkflowProfile>
<Name>default</Name>
<RestoreRetryAttempts>3</RestoreRetryAttempts>
<Messages>
<Message>Copy</Message>
<Message>Archive</Message>
<Message>Restore</Message>
<Message>Delete</Message>
<Message>Cancel</Message>
<Message>AllInfo</Message>
<Message>PartialRestore</Message>
</Messages>

<!-- SITE TO SITE TRANSFER CONFIG -->
<Mappings>
<SiteToSiteTransfer>
<!-IF transferring…-->
<FromSitename>diva1</FromSitename>
<ToSitename>diva2</ToSitename>
<!-THEN use these…-->
<FromSrcDest>viva</FromSrcDest>
<Type>RestoreAndArchive</Type>
<ToDefaultMedia>disk_001</ToDefaultMedia>
<ToSrcDest>arch</ToSrcDest>
</SiteToSiteTransfer>
<SiteToSiteTransfer>
<!-IF transferring…-->
<FromSitename>diva2</FromSitename>
<ToSitename>diva1</ToSitename>
<!-THEN use these…-->
<FromSrcDest>viva</FromSrcDest>
<Type>RestoreAndArchive</Type>
<ToDefaultMedia>disk_002</ToDefaultMedia>
<ToSrcDest>arch</ToSrcDest>
</SiteToSiteTransfer>
</Mappings>
</WorkflowProfile>
</config>

Exemple de configuration ManagerAdapter

<config>
<!-- TOP-LEVEL -->
<LocalSiteName>diva1</LocalSiteName>
<ManagerAddress>127.0.0.1</ManagerAddress>
<ManagerPort>9000</ManagerPort>
<LogLevel>INFO</LogLevel>
<WebServicePort>9800</WebServicePort>

<!-- Manager DATABASE -->
<ManagerDatabase>
<Address>127.0.0.1</Address>
<Port>1521</Port>
<User></User>
<Password></Password>
</ManagerDatabase>
</config>

Exemple de configuration DbSync

<config>
<!-- TOP-LEVEL -->
<LocalSiteName>diva1</LocalSiteName>
<LogLevel>INFO</LogLevel>
<WebServicePort>9802</WebServicePort>

<!-Sites to SYNC -->
<DivaManagers>
<DivaManager>
<Sitename>diva1</Sitename>
<BaseUrl>https://127.0.0.1:9800</BaseURL>
</DivaManager>
<DivaManager>
<Sitename>diva2</Sitename>
<BaseUrl>https://172.16.3.59:9800</BaseURL>
</DivaManager>
</DivaManagers>

<!-- DIVAnet DATABASE -->
<DivanetDatabase>
<Address>127.0.0.1</Address>
<Port>1521</Port>
<User></User>
<Password></Password>
</DivanetDatabase>
</config>

Glossaire

Archive Exchange Format (AXF)

Format indépendant de tout fournisseur, pris en charge par DIVArchive, pour le stockage de contenu sur différents médias (bande et disque notamment). Il peut stocker de nombreux fichiers et répertoires dans un seul fichier (conteneur) à l'instar d'un fichier ZIP.

Demande de contenu

Opération système traitant du contenu archivé (archivage, copie, suppression, restauration).

Répertoire de base DIVAnet

Répertoire du système de fichiers où DIVAnet est installé. DIVAnet peut être installé dans son propre répertoire (recommandé) ou dans le répertoire de base DIVArchive.

Objet DIVAnet (actif)

Un objet archivé représente du contenu numérique dans le système d'archivage. Un objet DIVAnet est un ensemble d'objets d'archivage, archivé sur un ou plusieurs sites DIVArchive, partageant le même nom (paire nom-catégorie d'objet). Chaque objet sur un site donné peut avoir une ou plusieurs copies (instances d'objet).

Site DIVAnet

Nom de site identifiant, de façon univoque, un site DIVAnet, qui est défini comme une installation DIVArchive et un ou plusieurs services DIVAnet.

Drop Folder Monitor (DFM)

Le service DFM de DIVArchive surveille le contenu qui est écrit sur disque dans un dossier. Il effectue ensuite l'opération affectée à ce dossier (archivage, restauration, copie, etc.) pour le contenu (placé dans le dossier) dans un système DIVArchive, après que le contenu a été entièrement écrit dans l'emplacement supérieur du dossier.

Copie intersite

Opération qui copie le contenu d'un site DIVA vers un autre, en archivant le contenu dans le site cible.

Transfert intersite

Opération qui déplace le contenu d'un site vers un autre, mais qui n'archive pas le contenu dans le site cible.

Média

Nom représentant un ensemble de médias d'archivage (disques ou bandes) dans un système DIVA. Il existe un média par copie d'un actif.

Mode MultiDiva

Quand un client d'API est connecté à DIVAnet en mode MultiDiva, de multiples sites DIVArchive s'affichent pour le client sous la forme d'un grand système d'archivage.

Mappage de site à site

Décrit la façon dont DIVAnet copie les objets d'un site à un autre.

Source/destination

Contient les informations nécessaires pour communiquer avec un serveur ou un disque connecté. Vous transférez du contenu depuis et vers DIVArchive via ces serveurs et disques. Exemples : serveurs vidéo, serveurs FTP et baies de disques.

Storage Plan Manager (SPM)

Vous pouvez configurer le service Oracle DIVArchive Storage Plan Manager (SPM) pour qu'il effectue automatiquement une opération quand le contenu arrive sur un site DIVArchive (restauration ou copie, par exemple).

Profil de workflow

Ensemble de paramètres qui définit comment les demandes entrantes seront traitées par DIVAnet. Il est possible de créer plusieurs profils et de les mapper avec des ports d'entrée.

Avis juridiques d'Oracle

Copyright

Copyright © 1994-2016, Oracle et/ou ses affiliés. Tous droits réservés.

Restrictions de licence/Avis d'exclusion de responsabilité en cas de dommage indirect et/ou consécutif

Ce logiciel et la documentation qui l'accompagne sont protégés par les lois sur la propriété intellectuelle. Ils sont concédés sous licence et soumis à des restrictions d'utilisation et de divulgation. Sauf stipulation expresse de votre contrat de licence ou de la loi, vous ne pouvez pas copier, reproduire, traduire, diffuser, modifier, accorder de licence, transmettre, distribuer, exposer, exécuter, publier ou afficher le logiciel, même partiellement, sous quelque forme et par quelque procédé que ce soit. Par ailleurs, il est interdit de procéder à toute ingénierie inverse du logiciel, de le désassembler ou de le décompiler, excepté à des fins d'interopérabilité avec des logiciels tiers ou tel que prescrit par la loi.

Exonération de garantie

Les informations fournies dans ce document sont susceptibles de modification sans préavis. Par ailleurs, Oracle Corporation ne garantit pas qu'elles soient exemptes d'erreurs et vous invite, le cas échéant, à lui en faire part par écrit.

Avis sur la limitation des droits

Si ce logiciel, ou la documentation qui l'accompagne, est livré sous licence au Gouvernement des Etats-Unis, ou à quiconque qui aurait souscrit la licence de ce logiciel pour le compte du Gouvernement des Etats-Unis, la notice suivante s'applique :

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware and/or documentation and technical data delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to U.S. Government.

Avis sur les applications dangereuses

Ce logiciel ou matériel a été développé pour un usage général dans le cadre d'applications de gestion des informations. Ce logiciel ou matériel n'est pas conçu ni n'est destiné à être utilisé dans des applications à risque, notamment dans des applications pouvant causer un risque de dommages corporels. Si vous utilisez ce logiciel ou ce matériel dans le cadre d'applications dangereuses, il est de votre responsabilité de prendre toutes les mesures de secours, de sauvegarde, de redondance et autres mesures nécessaires à son utilisation dans des conditions optimales de sécurité. Oracle Corporation et ses affiliés déclinent toute responsabilité quant aux dommages causés par l'utilisation de ce logiciel ou matériel pour des applications dangereuses.

Marques

Oracle et Java sont des marques déposées d'Oracle Corporation et/ou de ses affiliés. Tout autre nom mentionné peut correspondre à des marques appartenant à d'autres propriétaires qu'Oracle.

Intel et Intel Xeon sont des marques ou des marques déposées d'Intel Corporation. Toutes les marques SPARC sont utilisées sous licence et sont des marques ou des marques déposées de SPARC International, Inc. AMD, Opteron, le logo AMD et le logo AMD Opteron sont des marques ou des marques déposées d'Advanced Micro Devices. UNIX est une marque déposée de The Open Group.

Avis d'exclusion de responsabilité concernant les services, produits et contenu tiers

Ce logiciel ou matériel et la documentation qui l'accompagne peuvent fournir des informations ou des liens donnant accès à des contenus, des produits et des services émanant de tiers. Oracle Corporation et ses affiliés déclinent toute responsabilité ou garantie expresse quant aux contenus, produits ou services émanant de tiers, sauf mention contraire stipulée dans un contrat entre vous et Oracle. En aucun cas, Oracle Corporation et ses affiliés ne sauraient être tenus pour responsables des pertes subies, des coûts occasionnés ou des dommages causés par l'accès à des contenus, produits ou services tiers, ou à leur utilisation, sauf mention contraire stipulée dans un contrat entre vous et Oracle.

Avis sur les projets alpha et bêta de la documentation

Si cette documentation est fournie en version préproduction:

Cette documentation est fournie en version pré-production et uniquement à des fins de démonstration et d’usage à titre préliminaire de la version finale. Celle-ci n'est pas toujours spécifique du matériel informatique sur lequel vous utilisez ce logiciel. Oracle Corporation et ses affiliés déclinent expressément toute responsabilité ou garantie expresse quant au contenu de cette documentation. Oracle Corporation et ses affiliés ne sauraient en aucun cas être tenus pour responsable des pertes subies, des coûts occasionnés ou des dommages causés par l'utilisation de cette documentation.

Avis sur les projets alpha et bêta de la documentation à caractère privé

Si cette documentation est fournie en version préproduction à caractère privé :

Les informations contenues dans ce document sont fournies à titre informatif uniquement et doivent être prises en compte en votre qualité de membre du customer advisory board ou conformément à votre contrat d'essai de version bêta uniquement. Ce document ne constitue en aucun cas un engagement à fournir des composants, du code ou des fonctionnalités et ne doit pas être retenu comme base d'une quelconque décision d'achat. Le développement, la commercialisation et la mise à disposition des fonctions ou fonctionnalités décrites restent à la seule discrétion d'Oracle.

Ce document contient des informations qui sont la propriété exclusive d'Oracle, qu'il s'agisse de la version électronique ou imprimée. Votre accès à ce contenu confidentiel et son utilisation sont soumis aux termes de vos contrats, Contrat-Cadre Oracle (OMA) Contrat de Licence et de Services Oracle (OLSA), Contrat Réseau Partenaires Oracle (OPN), contrat de distribution Oracle ou de tout autre contrat de licence en vigueur que vous avez signé et que vous vous engagez à respecter. Ce document et son contenu ne peuvent en aucun cas être communiqués, copiés, reproduits ou distribués à une personne extérieure à Oracle sans le consentement écrit d'Oracle. Ce document ne fait pas partie de votre contrat de licence. Par ailleurs, il ne peut être intégré à aucun accord contractuel passé avec Oracle ou ses filiales ou affiliés.

Accessibilité de la documentation

Pour plus d'informations sur l'engagement d'Oracle pour l'accessibilité à la documentation, visitez le site Web Oracle Accessibility Program, à l'adresse : http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc.

Accès aux services de support Oracle

Les clients Oracle qui ont souscrit un contrat de support ont accès au support électronique via My Oracle Support. Pour plus d'informations, visitez le site http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info ou le site http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs si vous êtes malentendant.