Multipliez les bras de disques

Quand plusieurs bras d’un disque sont alloués au journal, l’IBM i envoie les entrées de journal à chaque bras à tour de rôle, pour diviser la charge à égalité entre eux. Cela augmente la probabilité que le bras écrive l’entrée de journal qui lui a été attribuée, avant qu’une autre entrée ne soit prête à lui être envoyée.

« Notre principal conseil aux clients est de configurer le matériel pour bien journaliser, » recommande Owen. « Vous devez mettre vos récepteurs de journaux dans leur propre ASP, puis leur offrir beaucoup de bras en utilisant vos bras et votre adaptateur d’I/O les plus rapides. »

La non-observation de ce conseil est souvent la cause des problèmes de performance. « À l’époque lointaine du System/38, on mettait de côté un ASP utilisateur pour les récepteurs de journaux, » note Owen. « Nous voyons encore quelques clients procéder ainsi aujourd’hui. Ils prennent de vieux disques démodés – peut-être deux ou trois – et peut-être un IOP, qu’ils utilisent comme récepteurs de journaux. Ils ont ainsi leurs disques les plus anciens et les plus lents et leur IOP le plus ancien et le plus lent, mais ils leur confient la plus grande part de leur activité disque, parce que le journal est probablement la partie la plus gourmande en disque du système d’exploitation, en dehors bien sûr de la sauvegarde et de la restauration. »

Synchronisation

Si vous utilisez la journalisation à distance, peut-être dans le cadre d’une solution haute disponibilité (HA), sachez qu’elle influence la performance des applications. Si la journalisation est en mode synchrone, le journal tentera de freiner la mise en cache des entrées de journal pour favoriser leur envoi à la cible distante, le plus rapidement possible. Qui plus est, en mode synchrone, la transaction locale n’est considérée terminée que quand l’entrée de journal est reçue par le système à distance et qu’un accusé de réception a été renvoyé. Cela peut entraîner des temps de réponse inacceptables.

À l’inverse, le mode asynchrone envoie les entrées de journal au système à distance indépendamment du traitement et de la journalisation des transactions locales, ce qui influe peu sur les temps de réponse de l’application. L’inconvénient est évident : si le datacenter principal est frappé par un sinistre, toutes les entrées de journal qui n’ont pas encore été transmises risquent d’être perdues si vous devez basculer la production sur le système de secours à distance.

Si les systèmes source et cible ont assez de capacité et s’il y a suffisamment de bande passante entre les deux, la latence des entrées de journal devrait être négligeable en mode asynchrone. C’est pourquoi la plupart des entreprises rejettent le mode synchrone pour éviter d’allonger les temps de réponse des applications. Mais ne perdez pas de vue le risque de perte de données, aussi petit soit-il.

Un autre problème de performance se pose avec des journaux à distance multiples. Au lieu de diffuser par broadcast les entrées de journal à tous les journaux à distance, adoptez plutôt une topologie en cascade ou une combinaison de cascade et de chemins de transmission broadcast.

En cascade, le système principal envoie les entrées de journal à l’un des systèmes à distance, lequel les transmet à l’un des autres et ainsi de suite jusqu’à ce que tous les journaux à distance aient été actualisés. Autre variante : le système principal envoie les entrées de journal à l’un des systèmes à distance. Le deuxième système diffuse ensuite les entrées aux autres journaux à distance. Par rapport à une topologie broadcast pure, l’avantage du mode cascade ou combinaison de cascade et broadcast, est de réduire le traitement sur le système de production et, en réduisant les backlogs, de transmettre les entrées de journal à au moins l’un des systèmes à distance, le plus rapidement possible.