2 Comment fonctionne ELS ?

Ce chapitre décrit le fonctionnement d'ELS.

Comment fonctionne SMC ?

Le composant SMC effectue les opérations suivantes :

  • Influence l'allocation des bandes selon des stratégies et en fonction des caractéristiques de volume et de lecteur fournies par HSC/VTCS :

    Par exemple, la commande POLICY de SMC peut servir à diriger les allocations de vidage vers des périphériques réels ou virtuels, à sélectionner des sous-pools de travail et à assigner un nom de classe de gestion que VTCS utilisera pour gérer les volumes virtuels.

  • Intercepte les messages de montage, démontage et de remplacement de MVS et les dirige vers HSC ou VTCS à des fins d'automatisation.

Le composant SMC doit s'exécuter sur chaque hôte sur lequel un traitement de bande a lieu. Le composant serveur d'ELS (HSC/VTCS) peut s'exécuter sur le même hôte z/OS que le composant SMC. Il peut également s'exécuter sur un hôte distant différent. Si SMC et HSC/VTCS se trouvent sur des hôtes z/OS différents, le protocole TCP/IP est utilisé pour envoyer des demandes depuis l'hôte client vers l'hôte serveur. Pour permettre la réception de demandes HTTP d'un client SMC distant, le composant HTTP doit être activé sur le SMC s'exécutant sur l'hôte serveur.

La fonctionnalité client/serveur de SMC vous permet d'exécuter SMC uniquement sur les hôtes client et HSC/VTCS et le serveur HTTP sur un ou plusieurs hôtes serveur. Cette fonctionnalité offre les avantages suivants :

  • Réduit le nombre d'hôtes sur lesquels vous exécutez HSC/VTCS. Oracle recommande d'exécuter HSC/VTCS sur deux hôtes seulement (principal et secours). L'exécution de HSC/VTCS sur un nombre d'hôtes moins élevé réduit les conflits d'utilisation des jeux CDS et épargne la gestion de plusieurs fichiers syslog MVS.

  • Communique avec plusieurs systèmes TapePlex HSC/VTCS représentant physiquement différentes configurations matérielles.

  • Fournit des fonctions de basculement lorsqu'un HSC est réutilisé à des fins de maintenance.

Comment fonctionne HSC ?

HSC contrôle l'environnement de bande physique. HSC, en réponse aux demandes provenant de SMC, ordonne à un robot ou HandBot LSM de monter et de démonter des bandes physiques. HSC contrôle également les autres opérations de bande physique, y compris les déplacements, les remplacements, etc. HSC gère également le jeu de données de contrôle (CDS) dans lequel sont stockées les informations relatives aux environnements de bande réels et virtuels.

Comment fonctionne VTCS ?

Le sous-système VTSS fournit des lecteurs de bande virtuels (VTD) qui émulent des périphériques 3490E. VSM utilise les lecteurs VTD pour écrire des données sur les volumes de bande virtuels (VTV) du VTSS.

VTCS est le logiciel qui contrôle le matériel VTSS. Par exemple, vous indiquez les seuils de migration automatique (AMT) haut et bas de VTSS, lesquels contrôlent la gestion d'espace de VTSS/le cycle de migration des VTV. Les lecteurs de bande réels (RTD) écrivent les volumes VTV migrés sur des cartouches multivolumes physiques (MVC). VTCS contrôle les lecteurs RTD (même si HSC fournit des services de montage et de démontage pour les MVC), tandis que HSC contrôle les lecteurs de bande ACS qui ne sont pas alloués au gestionnaire VSM.

Si l'hôte demande le montage d'un volume VTV qui a été migré vers une cartouche MVC et ne se trouve pas sur le système VTSS, VSM rappelle automatiquement le volume VTV migré vers le VTSS. La Figure 2-1 illustre le cycle de migration/rappel des VTV.

Remarque :

VSM prend en charge le partage dynamique des lecteurs RTD entre les sous-systèmes VTSS. Cependant, si les sous-systèmes VTSS partagent des lecteurs RTD, ils doivent avoir accès aux mêmes hôtes..

Figure 2-1 Cycle de migration/rappel des VTV

Le texte environnant décrit Figure 2-1 .

  1. Migration - jeu de données à montage virtuel enregistré sur volume VTV, démontage virtuel du VTV résidant sur le VTSS, le VTV est collecté avec d'autres VTV, montage réel du VTV empilé sur une cartouche MVC et démontage réel.

  2. Rappel - montage réel pour le rappel du VTV, VTV rappelé vers le VTSS, et montage virtuel.

Comment fonctionne le test CDRT ?

La fonction CDRT crée une copie de test du jeu CDS de production utilisé par les hôtes de récupération après sinistre et permet donc à deux sous-systèmes ELS dotés de deux jeux CDS différents de gérer le même matériel ACS. Le jeu CDS reflète les changements d'état des cartouches de bande et des ressources dans le matériel ACS. Cependant, au cours d'un test de récupération après sinistre avec la fonction CDRT, les deux sous-systèmes ELS utilisent deux jeux CDS différents et ne communiquent pas. Par conséquent, les changements qui ont lieu dans le jeu CDS de production ne sont pas représentés dans la copie de jeu CDS de test et inversement. La fonction CDRT agit de sorte à isoler le matériel ACS et VSM de test du matériel ACS et VSM de production, en gérant le test de récupération après sinistre de sorte à garantir l'intégrité des données de production et en réduisant les conflits d'utilisation des volumes de bande et des ressources matérielles ACS. La clé de la réussite d'un test de récupération après sinistre avec la fonction CDRT est une copie ponctuelle valide de l'état de tous les volumes de bande gérés par le matériel ACS et/ou VSM et le sous-système ELS. Dans un environnement de volume de bande, il arrive souvent que des données d'état (métadonnées) de ce volume de bande soient conservées et gérées en dehors du sous-système ELS et du matériel ACS/VSM. Généralement, les métadonnées de volume de bande (par exemple, VOLSER, DSN, date d'expiration, état de travail, désignation réelle ou virtuelle, etc.) sont stockées dans un ou plusieurs catalogues de gestion de bandes (TMC), un ou plusieurs catalogues z/OS et le jeu CDS. S'assurer que l'état des volumes de bande tel qu'il est représenté sur les systèmes hôte est le même ou équivalent sur les hôtes de production et les hôtes de récupération après sinistre est une condition critique pour la bonne exécution d'un test de récupération après sinistre. C'est cette cohérence dans l'état des volumes de bande entre les hôtes de production et les hôtes de récupération après sinistre au démarrage du test de récupération après sinistre qui permet le traitement parallèle des applications client et ainsi favorise la validation d'un plan de continuité de l'activité. Les hôtes de test de récupération après sinistre utilisent le matériel isolé tandis que les hôtes de production continuent d'utiliser le matériel ACS à la fois non isolé et isolé.

Le matériel de test de récupération après sinistre doit être composé au minimum d'un système ACS. Eventuellement, un ou plusieurs VTSS peuvent être employés comme matériel de test de récupération après sinistre. L'ACS est partagé entre les hôtes de production et les hôtes de récupération après sinistre. Les hôtes de récupération après sinistre jouissent de l'utilisation exclusive des VTSS isolés au cours du test de récupération après sinistre. Pour produire des copies ponctuelles valides de catalogues TMC et de catalogues z/OS, reportez-vous à la documentation appropriée des logiciels tiers. A la fin d'un test de récupération après sinistre, toutes les données créées à partir des hôtes de test de récupération après sinistre, y compris la copie de test du jeu CDS, sont généralement abandonnées et le matériel isolé est redéployé dans l'environnement de production normal.