> Tech > Mettez votre journal à  distance au régime

Mettez votre journal à  distance au régime

Tech - Par Larry Youngren - Publié le 24 juin 2010
email

Dans l’article « Journal à distance », (iSeries News, mars 2006), je traitais de l’utilisation du journal à distance dans le cas d’une machine de production, où l’on veux employer un mécanisme de transport capable d’envoyer les entrées du journal, en temps réel, à un emplacement éloigné (distant) qui héberge une réplique des éléments de base de données les plus critiques : fichiers stream d’octets, zones de données et files d’attente de données.Voyons maintenant comment façonner un tel environnement de telle sorte que chaque gramme d’énergie investi dans votre couche de transport à distance soit utilisé au mieux. En quelque sorte, nous essayons de fabriquer du muscle et de perdre du gras.

Pour qu’un tel transport soit efficace, vous pouvez instaurer quelques étapes de personnalisation pour réduire le gras qui, sans cela, emprunterait le tuyau de communication entre la source et la machine cible. Chaque étape contribuera à produire un flux de journal plus maigre et plus concentré.

Mettez votre journal à  distance au régime

L’une des approches les plus efficaces est aussi l’une des plus faciles à appliquer. Elle consiste à placer une bifurcation sur la route et à accorder au journal votre permission pour orchestrer deux écritures disque sur la machine source, au lieu d’une. Les moutons vers la droite, les chèvres vers la gauche. En effet, le journal contient deux sortes d’entrées : celles que vous voulez voir normalement et celles qui sont normalement cachées. La figure 1 illustre ce principe.

Pour les besoins de cet exemple, nous imaginerons deux instances communes d’entrées de journal qui ont tendance à apparaître dans vos récepteurs de journaux: celles qui sont présentes pour ajouter de nouveaux enregistrements à un fichier physique (comme le PT = PUT dans la figure 1) et celles qui sont normalement cachées mais présentes pour le compte des changements du chemin d’accès (par exemple, les fichiers logiques indexés), comme l’AP de la figure 1.

Les entrées de journal visibles traditionnelles sont vos anciennes favorites (R/PT pour un put base de données, R/DL pour un delete base de données). Les entrées cachées sont là uniquement pour aider le système d’exploitation du côté source à récupérer les propriétés statistiques de vos fichiers et récupérer plus rapidement vos chemins d’accès (des moutures comme I/IV, que vous ne pouvez visualiser qu’en ajoutant le paramètre INCHIDENT à la commande DSPLRN). A noter que de telles entrées cachées, bien qu’elles ne soient visibles que si vous faites l’effort de les amener à la surface, n’en sont pas moins là et consomment de l’espace sur le système source.

Les entrées de journal cachées ont certes un rôle important, mais il n’est approprié que sur la machine de production/source. Elles n’entrent en jeu qu’au moment de l’IPL et elles ne bénéficient qu’à l’exhaustivité IPL de la machine source. Cette observation étant faite, on en conclut facilement qu’elles doivent être les chèvres et que la machine cible (et tout logiciel fonctionnant sur cette extrémité du fil de communication, comme votre logiciel de replay haute disponibilité) n’a que faire de telles entrées de journal et vous serait très reconnaissant de ne pas les envoyer. Vous pouvez créer une bifurcation sur la route de cet objectif (en filtrant les entrées cachées) en émettant simplement une commande CHGJRN sur le source, et en spécifiant RCVSIZOPT(*RMNINTENT). C’est aussi simple que cela.

Après quoi, seuls les moutons (les entrées de journal visibles et utiles, nécessaires et appréciées par le côté cible) s’écouleront. Les chèvres seront poussées de côté sur des surfaces disque séparées côté source et ne seront appelées que si un IPL anormal du source survient. Le trafic de communication résultant empruntant le fil sera réduit – souvent spectaculairement.

Voulez-vous avoir une idée de la quantité de gras que vous pourriez ainsi éliminer ? Il suffit d’une opération en deux étapes. Premièrement, affichez le contenu de votre jeu de récepteurs de journaux avec une commande DSP JRN, en spécifiant INCHIDENT afin que les entrées de journal normalement cachées apparaissent. Dirigez les résultats vers un fichier de sortie.

Deuxièmement, interrogez le fichier de sortie résultant, en additionnant les longueurs des entrées de journal qui seraient normalement cachées. Ces entrées sont reconnaissables à leur JOCODE: « I ». La requête résultante ressemblerait à ceci :

 Select sum(JOENTL) from LIB/OUTFILE where JOCODE = ‘I’

A la réflexion, certains lecteurs craignent peut-être que, une fois la bifurcation en place, ils doivent émettre deux écritures disque au lieu d’une. Pas de panique ! Les deux écritures sur le côté source se chevauchent et sont effectuées en même temps sur des unités de disque séparées. Les moutons et les chèvres sont dirigés simultanément vers leurs granges respectives. Comme conséquence, seules les entrées de journal visibles se retrouvent sur le fil de communication et voyagent jusqu’à l’autre côté.

Le résultat est évident : mois de gras sur le fil et moins d’octets à traiter sur la cible, généralement sans augmentation notable du temps de réponse côté source.

Téléchargez gratuitement cette ressource

Les atouts du XDR face aux attaques modernes

Les atouts du XDR face aux attaques modernes

Agréger et corréler des données issues de plusieurs couches de sécurité permet de détecter et répondre plus rapidement aux menaces, gérer davantage d’alertes et renforcer la sécurité IT. La vague XDR s’accélère, comment en tirer profit ?

Tech - Par Larry Youngren - Publié le 24 juin 2010