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.