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 dans le 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 se connecteront aux 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 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 donné, indiqué par le paramètre <LocalSitename> dans les fichiers de configuration DIVAnet. Vous pouvez configurer de multiples sites DIVAnet, chacun avec ou sans accès client local. Les sites peuvent communiquer entre eux et répliquer mutuellement leurs informations.

Le type le plus basique de connectivité DIVAnet 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, voir Configuration des ports API client.

Pour que de multiples sites DIVA puissent être gérés comme un seul grand système d'archivage, les sites DIVAnet doivent être connectés ensemble à l'aide des 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 d'actif, surveiller le statut du site distant et envoyer des demandes au site (demande de restauration, par exemple), pour satisfaire les demandes de niveau DIVAnet. La richesse de cette interaction permet à DIVAnet de fonctionner comme un grand 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. Dallas est parfait pour représenter ce scénario, car il n'a pas de clients locaux à servir. Vous verrez comment Dallas est connecté à New York. Vous verrez ensuite comment configurer un site pour l'accès client, en examinant New York et Los Angeles, et la façon dont ils sont connectés.

Services DIVAnet

Un service DIVAnet est un service Windows installé sur un serveur, 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 sur un site a les mêmes nom et catégorie d'objet que sur un autre site, DIVAnet considère les deux comme étant le même objet.

Quand des actifs sont archivés à l'aide de DIVAnet, DIVAnet rejettera (par défaut) les nouveaux actifs qui ont les mêmes nom (et catégorie) que les actifs déjà archivés sur d'autres sites. En revanche, les archivages émis directement à un système DIVArchive ne feront pas l'objet de cette vérification. Si vous procédez à l'archivage sans utiliser DIVAnet, vous risquez de vous retrouver avec un objet sur le site B ayant un contenu différent de l'objet correspondant sur le site A. Ce qui peut faire que DIVAnet, à son tour, restaurera le mauvais contenu.

Dans DIVArchive, chaque objet archivé peut contenir de nombreuses instances : une instance pour chaque copie physique de l'objet sur bande ou sur disque. Il y a un numéro d'ordre pour chaque instance. 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 sur un système DIVA, de façon unique, en indiquant le nom de l'objet, la catégorie et le numéro d'ordre de l'instance.

DIVAnet affecte ses propres jeux de numéros d'ordre d'instance qui sont dérivés des numéros d'ordre d'instance DIVArchive. Il procède ainsi afin que, pour chaque objet, les numéros d'ordre d'instance DIVAnet soient uniques sur l'ensemble des sites DIVAnet.

Sources/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. Si une source/destination sur un site a le même nom qu'une autre sur un autre site, DIVAnet suppose qu'elles font référence aux mêmes serveur et disque physiques.

Cette convention est importante dans la configuration d'un système DIVAnet (pour plus d'informations, voir Workflow de restauration). Si les sources/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 pour transférer du contenu d'un site vers un autre, configurez au moins une source/destination pour qu'elle soit accessible à partir des deux sites. Cette source/destination commune sera utilisée par DIVAnet pour copier des objets d'un site vers l'autre. Les configurations de source/destination sur les deux sites doivent avoir 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, et peuvent même avoir des chemins racine différents dans la configuration. Par exemple, une source/destination nommée NY_SHOWS pourrait être du 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 intersite, ne configurez pas la source/destination pour transcodage à la restauration. Cela provoquerait l'archivage de contenu incorrect dans des 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 intersite (opérations de copie d'un site à un autre) en activant l'option AXF Genuine Checksums dans DIVArchive. Dans l'utilitaire de configuration DIVArchive, sélectionnez la source/destination que vous utilisez 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 et vérifiées par rapport au site cible.

Ne soyez pas perturbé par le paramètre Site figurant dans le panneau Source/Destination de l'utilitaire de configuration DIVArchive. Ici, le nom de site n'est utilisé que par DIVA et ne correspond pas à un site DIVAnet (pour plus d'informations, reportez-vous au Guide d'installation et de configuration d'Oracle DIVArchive).

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 offre une fonction similaire mais peut éventuellement 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 distant.