6 Utilisation de configurations VTSS en cluster

Les VTSS en cluster vous permettent de copier des VTV entre deux VTSS. Un VTSS en cluster est un outil puissant pour des applications telles que les solutions de récupération après sinistre (DR), mais pas seulement. Les sections suivantes décrivent les principes fondamentaux des clusters VTSS, ainsi que leur fonctionnement 

Voici également des variantes et fonctionnalités supplémentaires de VTSS en cluster que vous devez connaître :

Définition d'un VTSS en cluster

Un cluster VTSS est une solution de haute disponibilité (HA, High Availability) qui permet d'optimiser la disponibilité des données. Elle se compose de plusieurs systèmes VTSS connectés à l'aide de liens de communication (CLINK) FICON ou TCP/IP. En outre, chaque système VTSS au sein du cluster peut accéder à l'ensemble des données créées dans le cluster (VTSS résident ou migré). Les données (VTV) créées sur un cluster sont répliquées entre deux systèmes VTSS situés au sein du même cluster sous le contrôle de stratégies VTCS.

Remarque :

Pour s'assurer que chaque système VTSS peut accéder à toutes les données créées au sein du cluster, les configurations en cluster peuvent se présenter comme suit :

  • chaque VTSS figurant dans le cluster est connecté à des RTD ou VLE ;

  • "sans bandes" - aucun VTSS n'est connecté à des VLE ou RTD.

Les configurations en cluster offrent donc la meilleure disponibilité de données avec une récupération à chaud si un VTSS situé dans un cluster est victime d'une panne (les données répliquées restent disponibles sans qu'il soit nécessaire de recourir à des rappels à partir de MVC).

Avant VTCS 7.0, un cluster ne pouvait être composé que de deux VTSS. Depuis VTCS 7.0, un cluster peut comprendre un grand nombre de VTSS. Toutefois, un VTV peut uniquement se trouver dans deux VTSS à un moment donné.

Un cluster peut s'étendre sur plusieurs emplacements géographiques. Cependant, un cluster doit se trouver au sein d'un TapePlex unique (contrôlé par un seul CDS).

Un VTV peut être répliqué (copié) entre deux VTSS :

  • De façon asynchrone par rapport à la création de VTV. Exécution programmée dès que possible après le démontage de VTV.

  • De façon synchrone par rapport à la création de VTV. Le démontage de VTV ne s'achèvera pas avant la fin de la réplication.

Remarque :

Pour la réplication synchrone, via des CLINK ou la réplication améliorée, le VTSS met fin à la réplication si celle-ci entraîne le dépassement du gestionnaire MIH (Missing Interrupt Handler).

Pour VSM 6 et VSM 7, la valeur de dépassement MIH peut être configurée de 20 à 45 minutes par incréments de 5 minutes. Pour VSM4 et VSM 5, la valeur de dépassement MIH peut être configurée à 20 ou 45 minutes. La valeur définie dans le VTSS doit correspondre à celle définie dans le mainframe.

Les connexions entre les VTSS d'un cluster peuvent être unidirectionnelles, lorsque les données (VTV) circulent dans un seul sens, ou bidirectionnelles, lorsque les données (VTV) peuvent circuler dans les deux sens. L'utilitaire CONFIG indique si un cluster est unidirectionnel ou bidirectionnel, tandis qu'une classe de gestion de VTV détermine sa stratégie de réplication, le cas échéant, et si la réplication s'effectue de façon synchrone ou asynchrone.

Ainsi, l'archivage sécurisé de MVC (tel que décrit à la section Utilisation de la fonction d'archivage sécurisé externe d'ELS) et la réplication VTV peuvent tous deux faciliter la mise en place d'une solution de continuité de l'activité/récupération après sinistre. Toutefois, la réplication VTV présente plus d'avantages qu'une solution de haute disponibilité car :

  • les données peuvent être sauvegardées de façon synchrone ;

  • les données récentes, qui ont été répliquées sur un VTSS "de récupération", peuvent être restaurées plus rapidement, car vous n'avez pas besoin de monter des MVC.

Conditions requises pour les VTSS en cluster

Le Tableau 6-1 présente les conditions requises pour les VTSS en cluster.

Tableau 6-1 Conditions requises pour les VTSS en cluster

Composant Conditions requises

Clusters étendus

Microcode VTSS D02.07.00.00 ou niveau ultérieur pour les VSM4 ou VSM5 avec connexions FICON uniquement. Pour VSM 6 et VSM 7, tous les niveaux de microcode.

2 VTSS dans un cluster (interfaces ESCON)

Les VTSS principaux et secondaires peuvent représenter n'importe quelle combinaison de VSM4, dans laquelle la capacité du VTSS secondaire n'a pas d'importance. Les VSM5 ne possèdent pas d'interfaces ESCON et ne peuvent pas figurer dans un cluster avec d'autres VTSS utilisant ESCON.

2 VTSS dans un cluster (interfaces FICON)

Les VTSS principaux et secondaires peuvent représenter n'importe quelle combinaison de VSM4 et VSM5, dans laquelle la capacité du VTSS secondaire n'a pas d'importance. Par exemple, toutes les combinaisons suivantes sont admises :

  • VSM5 principal, VSM4 secondaire

  • VSM5 principal, VSM5 secondaire

  • VSM4 principal, VSM4 secondaire

  • VSM4 principal, VSM5 secondaire (non recommandé)

Microcode des VTSS principaux et secondaires

Le microcode du VTSS principal doit être à un niveau qui prend en charge l'envoi de VTV répliqués. Le microcode du VTSS secondaire doit être à un niveau qui prend en charge l'envoi de VTV répliqués et l'utilisation du VTSS secondaire comme VTSS de production. Une fois le microcode installé, la fonction de clustering doit être activée à la fois sur les VTSS principaux et secondaires à l'aide d'une disquette d'options. Pour plus de détails, consultez le représentant du service technique StorageTek.

VTD réservés au clustering

Dans les configurations VTSS en cluster, vous devez vérifier que les 16 premiers VTD de chaque VTSS (0-F) sont réservés au clustering. Ces périphériques doivent être HORS LIGNE sur MVS et leurs chemins doivent être en ligne sur chaque hôte serveur HSC. Il en va de même pour les VTSS entrant en jeu dans la fonction CTR (Cross TapePlex Replication). VTCS n'inscrit pas les 16 premiers VTD auprès de SMC/HSC, ce qui empêche le montage de VTV sur ces VTD.

RTD

Dans les environnements à deux ACS, les mêmes types de périphérique doivent être représentés dans les RTD connectés à chaque ACS de sorte que les données migrées par un VTSS d'un cluster puissent être rappelées par n'importe quel autre VTSS du cluster. Le nombre de MVC, le type de média et l'emplacement utilisés pour la migration sont déterminés par le paramètre MIGPOL de l'instruction MGMTclas.

Tous les ACS doivent être pris en compte. En outre, si un type d'unité dans un ACS est connecté à l'un des VTSS d'un environnement VTSS en cluster, une unité de même type et située dans le même ACS doit être connectée à tous les autres VTSS de cet environnement en cluster.

Protocole IP natif (clustering avec TCP/IP)

Le protocole IP natif requiert CDSLEVEL F ou niveau ultérieur, avec les PTF suivants :

  • Pour 6.2 :

    L1A00P7 - SMC6200

    L1H14IM - SMS6200

    L1H14O2 - SOS6200

    L1H14IL - SWS6200

  • Pour 7.0, L1H150G (SES7000)

  • Pour 7.1 et versions ultérieures, la prise en charge est incluse dans la base.

Les connexions suivantes sont prises en charge pour le protocole IP natif :

  • VSM5 à VSM5

  • VSM5 à VSM 6

  • VSM 6 à VSM 6

  • VSM 6 ou VSM5 à VLE

La réplication synchrone, qui s'applique uniquement à VSM4 et supérieur, répond aux exigences décrites dans le Tableau 6-2.

Tableau 6-2 Conditions requises pour la réplication synchrone

Condition requise pour la réplication synchrone Niveau de microcode VTSS Niveau de CDS

Ports FICON ou IP natifs pour les CLINK

Microcode niveau D02.03.00.00 ou suivant pour VSM4 et VSM5. Pour VSM 6 et VSM 7, tous les niveaux de microcode.

"F" ou niveau ultérieur

La réplication améliorée, qui s'applique à VSM6 et supérieur, présente les conditions requises décrites dans le Tableau 6-3.

Tableau 6-3 Conditions requises pour la réplication améliorée

Condition requise pour la réplication améliorée Niveau de microcode VTSS Niveau de CDS

Ports FICON ou IP natifs pour les CLINK

VSM 6.3.0.03.000 (6.3.0.05.000 recommandé) pour VSM 6 ; VSM 7.0.0.05.000 pour VSM 7.

Appliquer PTF L1H18MB.

"H" ou niveau ultérieur

Fonctionnement des configurations VTSS en cluster

Vous pouvez utiliser VSM pour connecter deux VTSS par des liens de cluster (CLINK) afin de générer une configuration VTSS en cluster. Utilisez les instructions ci-dessous pour implémenter une configuration en cluster.

  • Les clusters peuvent être unidirectionnels ou bidirectionnels en fonction des instructions CLINK.

  • Le VTSS secondaire (ou deuxième homologue) peut se trouver sur le même emplacement physique que le VTSS principal (ou premier homologue), ou sur un emplacement distant.

  • L'instruction CONFIG CLUSTER spécifie les VTSS qui forment le cluster.

  • L'instruction CONFIG CLINK définit les CLINK qui connectent les VTSS. Le mode d'écriture des instructions CLINK détermine si la réplication est unidirectionnelle ou bidirectionnelle. Pour obtenir des exemples, consultez les sections VTSS en cluster unidirectionnel et "VTSS en cluster bidirectionnel."

  • Le paramètre MGMTclas REPLICAT identifie la classe de gestion contenant les VTV que VSM réplique (copie) entre deux VTSS du cluster.

Le paramètre CONFIG GLOBAL REPLicat indique maintenant quand répliquer un VTV, comme suit :

REPLicat

spécifie quand VSM réplique le VTV.

ALWAYS

La demande de réplication est ajoutée à la file d'attente de réplication VTCS chaque fois que le VTV est démonté, qu'il ait été modifié ou non lors du montage(valeur par défaut).

CHANGED

La demande de réplication est ajoutée à la file d'attente de réplication VTCS si le VTV :

  • a été modifié lors de son montage ou

  • a été lu uniquement lors du montage mais un nombre de fois inférieur au nombre attendu de copies MVC existantes du VTV.

Quel que soit le paramètre CONFIG GLOBAL REPLicat, la réplication requiert également que les conditions ci-dessous soient remplies.

  • Le VTV doit être démonté dans un VTSS prenant en charge la réplication et il ne doit pas exister de copie identique du VTV dans l'autre VTSS au sein du cluster ;

  • Outre la valeur CONFIG GLOBAL REPLicat , vous devez indiquer REPLICAT(YES) sur la classe de gestion d'un VTV pour que la réplication ait lieu.

    Pour plus d'informations, reportez-vous au manuel Référence des commandes, des instructions de contrôle et des utilitaires ELS.

  • VTCS migre immédiatement (à l'aide de KEEP) les VTV répliqués. Vous pouvez indiquer le VTSS source pour la migration des VTV répliqués dans le paramètre MIGRATE de l'instruction STORclas. Notez également que vous devez spécifier la réplication sur une classe de gestion qui pointe vers une classe de stockage avec une valeur de paramètre MIGRATE pour effectuer la migration à partir du VTSS souhaité. Sinon, la migration à partir du VTSS souhaité peut ne pas avoir lieu.

    VTCS migrant immédiatement (à l'aide de KEEP) les VTV répliqués quel que soit le paramètre MGMTclas IMMDELAY, StorageTek recommande vivement de ne pas définir explicitement une stratégie MGMTclas IMMDELAY pour les VTV répliqués. Dans le cas contraire, VTCS honore la demande de migration explicite immédiate et migre immédiatement le VTV en question à partir du premier VTSS capable d'effectuer la migration (à savoir le premier VTSS disposant d'une copie VTV résidente et d'un RTD disponible pour réaliser la migration). La définition d'une stratégie MGMTclas IMMDELAY explicite est donc redondante et peut perturber les performances de réplication et de migration des VTV.

    Notez également que la migration immédiate (KEEP) qui suit la réplication n'est pas identique à la migration automatique. Ainsi, lors de la migration immédiate implicite, aucun VTV n'est supprimé d'un VTSS pour gérer la DBU. Les VTV sont simplement "pré-transférés" à l'aide de la migration vers un MVC à partir du VTSS récepteur, laissant alors le contenu des deux tampons VTSS en l'état. Pour la gestion d'espace dans un cluster VTSS, VTCS migre automatiquement les VTV en fonction du cycle de gestion d'espace/de migration de l'un des VTSS. Si la capacité du VTSS récepteur est supérieure ou égale à celle du VTSS émetteur, la migration automatique sur le VTSS émetteur supprime un VTV répliqué des deux VTSS. Si la capacité du VTSS récepteur est inférieure à celle du VTSS émetteur, la migration automatique peut démarrer sur le VTSS récepteur. Dans ce cas, la migration automatique supprime un VTV répliqué uniquement sur le VTSS récepteur, laissant la copie sur le VTSS émetteur.

  • Notez que les conditions requises pour la réplication des données sont déterminées à la suite d'un démontage et non après un rappel. Le rappel d'un VTV n'entraînera pas de réplication – par conséquent, le rappel selon les besoins, MVCdrain et la récupération ne provoqueront pas de réplication. Cependant, si le VTV est rappelé et monté sur un VTD, il sera répliqué sur le VTSS secondaire ou homologue lors du démontage.

  • Un cluster peut prendre en charge des charges globales différentes dans chacun des quatre modes de fonctionnement. Par exemple, seuls les clusters pleines fonctions peuvent prendre en charge la réplication active. Cependant, en mode principal dégradé, vous pouvez basculer en ligne les VTD du VTSS secondaire vers MVS pour reprendre la charge globale. Vous pouvez utiliser Query pour afficher l'e statut d'un cluster, d'un lien de cluster, d'une réplication et d'un VTSS. Vous pouvez utiliser VARY VTSS pour modifier les états des VTSS et VARY CLink pour modifier les états des CLINK.

Fonctionnement du rapprochement VTSS

  • Lorsqu'une paire de VTSS en cluster repasse à l'état pleines fonctions, VTCS rapproche le contenu des deux VTSS. Cela se produit lors de l'initialisation de VTCS ou lors du passage en ligne d'un VTSS, alors que son VTSS partenaire est également en ligne.

  • Le rapprochement consiste à supprimer ou migrer et supprimer des VTV (ou à répliquer un VTV si l'opération n'avait pas abouti précédemment). Le rappel n'entre donc pas en jeu dans le rapprochement du contenu des VTSS.

    Par exemple, dans un cluster unidirectionnel avec un VTV qui se trouve sur le VTSS récepteur mais pas sur le VTSS émetteur, VTCS supprime le VTV du récepteur (après s'être assuré que toutes les copies MVC requises ont été réalisées). Cela évite ainsi l'envoi d'un rappel à l'émetteur.

    De même, dans un cluster unidirectionnel avec un VTV qui se trouve sur le VTSS émetteur mais pas sur le VTSS récepteur, VTCS réplique le VTV sur le récepteur au lieu de le rappeler à partir d'un MVC.

  • Le processus de rapprochement suppose qu'un VTV répliqué qui se trouve sur le VTSS émetteur est une copie valide. Si la copie figurant sur le récepteur est différente, VTCS la supprime.

  • Pour que les opérations de rapprochement restent cohérentes dans un cluster bidirectionnel, le VTSS où se trouve le VTV ou il se trouvait la dernière fois (comme indiqué par l'enregistrement VTV du CDS), est considéré comme le VTSS émetteur. Le traitement du rapprochement décrit ci-dessus concerne les clusters unidirectionnels.

Clusters unidirectionnels et bidirectionnels

Les clusters de deux VTSS peuvent être :

  • unidirectionnels, si un VTSS est le VTSS principal et l'autre le VTSS secondaire. Pour plus d'informations, voir "VTSS en cluster unidirectionnel."

  • bidirectionnels, si les deux VTSS sont homologues et que la réplication s'effectue d'homologue à homologue dans n'importe quel sens. Pour plus d'informations, voir "VTSS en cluster bidirectionnel."

Clusters unidirectionnels

Comme indiqué à la Figure 6-1, dans un cluster unidirectionnel, la réplication s'effectue uniquement du VTSS principal vers le VTSS secondaire.

Figure 6-1 VTSS en cluster unidirectionnel

La description de Figure 6-1 est la suivante
Description de Figure 6-1 VTSS en cluster unidirectionnel

Fonctionnement des clusters VTSS unidirectionnels

  • Le VTSS secondaire peut recevoir les VTV répliqués du VTSS principal et la charge globale de production non répliquée à l'aide d'une des méthodes de routage standard (par exemple, TAPEREQ). Vous devez basculer en ligne les VTD du VTSS secondaire afin que ce dernier puisse accepter le travail de production. Vous ne pouvez pas basculer en ligne les adresses VTD utilisées par les interruptions CLINK vers MVS, comme décrit dans la section "Fonctionnement des configurations VTSS en cluster."

  • Un VTV pour lequel la réplication est activée est alloué à un VTSS principal en ligne, sauf si aucun d'eux n'est disponible, auquel cas le VTV est alloué à un VTSS secondaire en ligne. Si aucun VTSS secondaire en ligne n'est disponible, le VTV est alloué à un VTSS qui n'est pas un cluster. Un VTV sans réplication peut être alloué à n'importe quel VTSS en ligne, y compris le VTSS secondaire d'un cluster pleines fonctions.

  • Lors du démontage, un VTV pour lequel la réplication est activée et qui se trouve sur un cluster pleines fonctions est placé en file d'attente sur le VTSS secondaire. Si un VTV pour lequel la réplication est activée est démonté d'un VTD dans un VTSS qui ne fait pas partie d'un cluster pleines fonctions, le VTV est placé en file d'attente en vue d'une migration immédiate.

    Lorsque le VTSS secondaire reçoit un VTV répliqué du VTSS principal, le VTV est alors immédiatement migré (à l'aide de l'option KEEP/) quels que soient les paramètres de l'option Immediate Migrate Management Class (migration immédiate de la classe de gestion) pour ce VTV.

  • Les VTSS principaux et secondaires peuvent tous gérer l'ensemble des récupérations d'espace.

  • Si vous utilisez des interfaces ESCON ou FICON, sur le VTSS principal, les CIP/FIP CLINK sont configurés en mode Nearlink, tandis que sur le VTSS secondaire, les CIP/FIP sont configurés en mode Hôte.

    Par conséquent, configurez les CLINK uniquement pour le VTSS principal, comme illustré dans l'exemple suivant, où VTSS1 correspond au VTSS principal.

    .
.
CLUSTER NAME=CLUSTER1 VTSSs(VTSS1,VTSS2)
 CLINK VTSS=VTSS1 CHANIF=0G
 CLINK VTSS=VTSS1 CHANIF=0O
 CLINK VTSS=VTSS1 CHANIF=1G
 CLINK VTSS=VTSS1 CHANIF=1O
.
.

Clusters bidirectionnels

Comme indiqué à la Figure 6-2, le clustering bidirectionnel requiert des paires de CLINK unidirectionnels, afin que les données circulent en sens opposé sur les CLINK.

Figure 6-2 VTSS en cluster bidirectionnel

La description de Figure 6-2 est la suivante
Description de Figure 6-2 VTSS en cluster bidirectionnel

Fonctionnement des clusters VTSS bidirectionnels

Dans un cluster bidirectionnel, en mode de fonctionnement normal, les deux VTSS sont en ligne sur VTCS, comme suit :

  • Dans un cluster bidirectionnel, chaque VTSS homologue peut recevoir un travail de production via les méthodes de routage standard (par exemple, TAPEREQ). Vous devez basculer en ligne les VTD des deux VTSS vers MVS, afin que chacun d'eux puisse accepter le travail de production. Toutefois, notez que vous ne pouvez pas basculer en ligne les adresses VTD utilisées par les connexions CLINK vers MVS, comme décrit dans la section "Fonctionnement des configurations VTSS en cluster."

  • Dans un cluster bidirectionnel, un VTV pour lequel la réplication est activée est alloué à l'un ou l'autre des VTSS homologues. Si l'un des deux VTSS homologues est hors ligne ou au ralenti, la charge globale de production peut s'exécuter sur le VTSS en ligne restant. Toutefois, les VTV nécessitant une réplication sont alloués au VTSS restant uniquement si aucun autre cluster pleines fonctions n'est disponible et adapté. Dans ce cas, les VTV répliqués sont migrés immédiatement à l'aide de KEEP et placés en file d'attente de réplication lorsque l'autre VTSS passe en ligne.

  • Dans un cluster bidirectionnel, lors du démontage, un VTV pour lequel la réplication est activée et qui se trouve sur un cluster pleines fonctions est placé en file d'attente de réplication sur l'autre VTSS homologue. Si un VTV pour lequel la réplication est activée est démonté d'un VTD dans un VTSS qui ne fait pas partie d'un cluster pleines fonctions, le VTV est placé en file d'attente en vue d'une migration immédiate. Notez que les conditions requises pour la réplication des données sont déterminées à la suite d'un démontage et non après un rappel. Le rappel d'un VTV n'entraînera pas de réplication – par conséquent, le rappel selon les besoins, MVCdrain et la récupération ne provoqueront pas de réplication. Toutefois, si le VTV est rappelé et monté sur un VTD, lors du démontage il sera répliqué sur le VTSS secondaire, à moins que vous n'indiquiez REPLICAT(CHANGED) (option recommandée), qui provoque à nouveau la réplication du VTV uniquement en cas de modification des données.

  • Les deux VTSS homologues peuvent gérer toutes les récupérations d'espace.

  • Si vous utilisez des interfaces ESCON ou FICON :

    • Sur chaque VTSS homologue, les CIP/FIP CLINK émetteur sont configurés en mode Nearlink, tandis que les CIP/FIP CLINK récepteur sont configurés en mode Hôte.

      Par conséquent, configurez les CLINK émetteur sur chaque VTSS homologue, comme illustré dans l'exemple suivant, où VSMPR1 et VSMPR2 sont des VTSS homologues.

      .
.
CLUSTER NAME=CLUSTER1 VTSSs(VSMPR1,VSMPR2)
 CLINK VTSS=VSMPR1 CHANIF=0O:0
 CLINK VTSS=VSMPR1 CHANIF=0O:1
 CLINK VTSS=VSMPR2 CHANIF=1O:0
 CLINK VTSS=VSMPR2 CHANIF=1O:1
.
.

  • Chaque CLINK doit être connecté au même cluster de stockage sur chaque VTSS (cluster de stockage 0 connecté au cluster de stockage 0 ou cluster de stockage 1 connecté au cluster de stockage 1). Si la configuration ne répond pas à cette exigence, vous risquez d'être confronté à des erreurs de réplication, de canal et de communication.

    Comme illustré dans l'exemple de la Figure 6-3, le port CLINK émetteur (mode Nearlink) sur VSMPR1 se trouve sur le cluster de stockage 1 et se connecte à un port CLINK récepteur (mode Hôte), qui se trouve également sur le cluster de stockage 1 de VSMPR2. De même, un port CLINK émetteur sur le cluster de stockage 0 de VSMPR2 se connecte à un port CLINK récepteur sur le cluster de stockage 0 de VSMPR1.

    Figure 6-3 CLINK ESCON/FICON pour VTSS en cluster bidirectionnels

    La description de Figure 6-3 est la suivante
    Description de Figure 6-3 CLINK ESCON/FICON pour VTSS en cluster bidirectionnels

Clustering étendu

Le clustering étendu permet à trois VTSS au minimum d'être connectés par des CLINK dans une configuration à un seul Tapeplex (1 CDS). Le clustering est une solution de haute disponibilité conçue de sorte qu'une charge globale puisse continuer à s'exécuter sans interruption lors d'une coupure VTSS. Le clustering requiert que tous les sous-systèmes VTSS appartenant à un cluster aient accès à tous les MVC générés par un seul sous-système VTSS dans ce cluster. Si un VTSS au sein d'un cluster se connecte à un Tapeplex distant (CTR), tous les systèmes VTSS du cluster doivent se connecter au même Tapeplex pour conserver la fonctionnalité HA.

Le clustering étendu permet de configurer un VSM avec des CLINK connectés à plusieurs VTSS. Le nombre de connexions CLINK se limite uniquement au nombre de connexions physiques disponibles. Le microcode D02.07.00.00 ou niveau supérieur est requis. Toutes les règles de clustering et de réplication disponibles s'appliquent au clustering étendu. Toutes les configurations de cluster étendu se fondent sur les deux configurations unidirectionnelles de base présentées à la Figure 6-4.

Figure 6-4 Configurations de cluster étendu de base

La description de Figure 6-4 est la suivante
Description de Figure 6-4 Configurations de cluster étendu de base

Réplication synchrone ou asynchrone

Vous avez le choix entre la réplication synchrone ou asynchrone, en fonction des stratégies en vigueur sur votre site.

Implémentation de la réplication synchrone

Attention :

Avec la réplication synchrone, le temps requis pour la réplication d'un volume virtuel retarde l'achèvement d'un travail de création de données soumis à une stratégie de réplication synchrone.

  1. Vérifiez que votre système répond aux conditions requises pour la réplication synchrone, qui sont décrites dans le Tableau 6-2.

  2. Lorsque tous les systèmes HSC/VTCS sont arrêtés, utilisez CONFIG GLOBAL pour activer la réplication synchrone :

    CONFIG GLOBAL SYNCHREP=YES

  3. Vérifiez que le paramètre CONFIG GLOBAL REPLICAT est défini comme vous le voulez :

    ALWAYS

    La demande de réplication est ajoutée à la file d'attente de réplication VTCS chaque fois que le VTV est démonté, qu'il ait été modifié ou non lors du montage(valeur par défaut).

    CHANGED

    La demande de réplication est ajoutée à la file d'attente de réplication VTCS si le VTV :

    • a été modifié lors de son montage ou

    • a été lu uniquement lors du montage mais un nombre de fois inférieur au nombre attendu de copies MVC existantes du VTV.

  4. Spécifiez la réplication synchrone dans les instructions MGMTClas souhaitées :

    MGMT (name) ..... REP(YES_SYNC)

Implémentation de la réplication asynchrone avec surveillance des travaux

Vous pouvez choisir d'utiliser la réplication asynchrone tout en voulant savoir si la réplication a abouti. Dans cette procédure, vous vous servez de l'utilitaire DRMONitr pour surveiller la suspension du travail MVS associé jusqu'à ce que la réplication aboutisse.

  1. Vérifiez que votre système répond aux conditions requises pour la réplication synchrone, qui sont décrites dans le Tableau 6-2.

  2. Lorsque tous les systèmes HSC/VTCS sont arrêtés, utilisez CONFIG GLOBAL pour activer la réplication asynchrone :

    CONFIG GLOBAL SYNCHREP=NO

  3. Vérifiez que le paramètre CONFIG GLOBAL REPLICAT est défini comme vous le voulez :

    ALWAYS

    La demande de réplication est ajoutée à la file d'attente de réplication VTCS chaque fois que le VTV est démonté, qu'il ait été modifié ou non lors du montage(valeur par défaut).

    CHANGED

    La demande de réplication est ajoutée à la file d'attente de réplication VTCS si le VTV :

    • a été modifié lors de son montage ou

    • a été lu uniquement lors du montage mais un nombre de fois inférieur au nombre attendu de copies MVC existantes du VTV.

  4. Spécifiez la réplication asynchrone dans les instructions MGMTClas souhaitées :

    MGMT (mgmtname) ..... REP(YES)

  5. Créez un JCL pour surveiller la réplication asynchrone.

    Pour ce faire, servez-vous de l'utilitaire DRMONitr afin de surveiller la réplication. DRMONitr provoque la suspension du travail MVS associé jusqu'à ce que la réplication aboutisse. Par exemple :

    //MONITOR EXEC PGM=SLUADMIN,PARM='MIXED'
//STEPLIB  DD DSN=hlq.SEALINK,DISP=SHR
//* If HSC IS NOT OR MAY NOT BE ACTIVE, INCLUDE THE 
//* FOLLOWING:
//SLSCNTL DD DSN=primary.cds.name,DISP=SHR
//SLSCNTL2 DD DSN=secondary.cds.name,DISP=SHR
//SLSSTBY   DD DSN=standby.cds.name,DISP=SHR
//SLSPARMP DD DSN=hlq.PARMLIB(BKPCNTL),DISP=SHR
//SLSPARMS DD DSN=hlq.PARMLIB(BKPCNTL2),DISP=SHR
//SLSPARMB DD DSN=hlq.PARMLIB(BKPSTBY),DISP=SHR
//SYSIN          DD UNIT=SYSDA,SPACE=(TRK,1)
//* THE FOLLOWING IS USED BY THE SNAPSHOT UTILITY:
//SYSPRINT  DD  SYSOUT=* 
//SLSPRINT   DD SYSOUT=* 
//SLSIN         DD *
DRMON MGMT(mgmtname) REPL MAXAGE(24) TIMEOUT(120)

Dans cet exemple, l'utilitaire DRMON surveille les réplications pour la classe de gestion spécifiée. En outre, surveillez uniquement les VTV qui ont été mis à jour au cours des dernières 24 heures et spécifiez le délai d'expiration de DRMON sur 120 minutes.

Clustering avec connexions TCP/IP

La fonctionnalité de connexion IP native de VTSS vous permet d'utiliser le protocole TCP/IP pour "mettre en cluster" (connecter) deux VTSS au minimum pour la réplication VTV. Avec le clustering IP natif, chaque VTSS dispose de ports Ethernet pour la connexion au réseau TCP/IP. Auparavant, vous étiez limité aux connexions ESCON ou FICON pour la réplication. L'utilisation de TCP/IP pour les CLINK permet d'améliorer les performances de réplication sur les protocoles ESCON ou FICON et, le cas échéant, d'utiliser les ports ESCON ou FICON existants exclusivement pour les connexions RTD et hôtes, où les combinaisons suivantes sont prises en charge :

  • VSM5 à VSM5

  • VSM5 à VSM 6

  • VSM 6 à VSM 6

Cette section décrit uniquement l'implémentation VTCS pour le protocole IP natif. Le personnel du support technique StorageTek ou les autres QSP sont responsables de la configuration VTSS annexe.

Environnement TCP/IP

Les CLINK connectés à TCP/IP ont la même fonction que les CLINK connectés à un canal FICON ou ESCON, mais un CLINK TCP/IP se connecte à l'aide d'un port Ethernet sur le VTSS et non à partir d'un port ESCON ou FICON. L'exemple de la Figure 6-5 présente des VSM5 homologues, chacun doté de 4 cartes IFF3 avec ports Ethernet. Les câbles Ethernet provenant des ports Ethernet sur les cartes IFF3 se connectent à des réseaux locaux (LAN, un pour chaque VTSS), qui sont eux-mêmes connectés via un réseau WAN.

Figure 6-5 Environnement TCP/IP avec deux VSM5

La description de Figure 6-5 est la suivante
Description de Figure 6-5 Environnement TCP/IP avec deux VSM5

Configuration de VTCS pour CLINK TCP/IP

Vous trouverez ci-dessous les paramètres pour l'instruction CONFIG CLINK.

Instruction CONFIG CLINK

L'instruction CONFIG CLINK fournit deux types de connexions VTSS à VTSS par le biais des paramètres suivants :

CLINK CHANIF=nn ou nn:n

définit un port FICON ou ESCON à utiliser comme CLINK.

CLINK IPIF=ci:p

définit un port Ethernet à utiliser comme CLINK. Les valeurs admises pour CONFIG RTD IPIF sont c=0 ou 1, i=A ou I, p=o à 3 pour les VSM5 et VSM 6. Pour les VSM5, cette valeur doit correspondre aux valeurs spécifiées dans l'écran IFF Configuration Status Screen du VSM5. Pour les VSM 6, la valeur doit être unique pour chaque VTSS et ne correspond pas à une valeur réelle sur les ports TCP/IP du VSM 6.

Remarque :

L'instruction CLINK doit contenir le paramètre CHANIF ou IPIF, mais pas les deux.