> Tech > Mais puis-je suivre ?

Mais puis-je suivre ?

Tech - Par Renaud ROSSET - Publié le 24 juin 2010
email

C’est bien sûr une approche simplissime et rudimentaire. Elle n’est pas optimisée pour la vitesse. Elle n’emploie pas de parallélisme côté cible. Elle n’effectue aucun traitement anticipé pour essayer de faire converger des lignes de la base de données répliquée dans la mémoire principale, avant d’essayer de les mettre à

Mais puis-je suivre ?

jour. Ce sont toutes des techniques que les produits HA haut de gamme utilisent souvent pour que le côté cible ne reste pas à la traîne. Et, bien sûr, s’il vous faut une approche de replay continue avec une permutation rapide de rôles assurée, vous devez faire de même. Donc il est naturel de vous demander : « Comment cette technique de replay à bon compte périodique peut-elle suivre le train quand le rythme d’arrivée des nouveaux changements de bases de données s’accélère ? »

Pour essayer de répondre à cette question, nous avons mis en scène un banal environnement de réception d’hôtel sur notre côté source et avons simulé la tenue d’une convention ou séminaire. Dans cet exemple, il a fallu sept instructions SQL pour enregistrer un invité ou participant, et nous avons traité plus de 500 invités par minute. Nous avons choisi de durcir la situation (probablement beaucoup plus que vous ne jugeriez prudent, mais nous voulions absolument mettre la pression côté cible) et nous avons changé les récepteurs de journaux toutes les 138 secondes. Par conséquent, nous avions plus de 8 700 entrées de journal, environ, à appliquer côté cible toutes les deux ou trois minutes.

Notre machine source était un modèle 840 à 12 voies en version V5R4. La machine cible était un modèle 520 à 4 voies. La figure 5 montre le résultat : nous avons produit 4 754 entrées de journal par minute côté source et reproduit ces mêmes entrées au rythme de 16 004 par minute, côté cible. A ce régime, le côté cible a facilement suivi le côté source. Dans des environnements plus exigeants, on pourrait diviser les tables SQL sous-jacentes sur des journaux plus distincts, de manière à accroître le parallélisme côté cible.

Pour durcir la comparaison, nous avons « bidouillé » certaines autres sessions, en réveillant et en changeant les récepteurs de journaux plus brutalement et moins brutalement que toutes les 138 secondes. Comme le montre le graphique, un rafraîchissement périodique toutes les 5 10 secondes est très brutal, et l’opération APYJRNCHGX résultante a du mal à suivre. Il est plus raisonnable de porter à 5-10 minutes le laps de temps entre les opérations de rafraîchissement. Il en est ainsi parce que, contrairement aux produits HA ajustés pour reprendre les lignes une à une avec un modeste overhead de démarrage pour chacune, la commande APYJRNCHGX intégrée ressemble davantage à un Boeing 747 roulant sur la piste : il lui faut un certain temps pour décoller. Mais, dès qu’il a atteint son altitude de croisière, il transporte beaucoup de passagers sur de longues distances. Il en est de même pour APYJRNCHGX. Cette commande n’est pas conçue pour traiter une image ligne à la fois, mais un grand nombre. Une fois lancée, elle effectue une mise à jour SLIC à SLIC de chaque ligne dont elle rencontre l’image. On peut juger de son efficacité en comparant les barres cible et source dans la figure 5.

Cependant, à cause du lourd overhead initial pour prendre son élan et atteindre la vitesse de croisière, APYJRNCHGX n’est vraiment pas l’outil idoine pour une approche continue ligne à ligne, une par une. Laissons cela aux vrais produits HA du marché. Nous avons ici un simple apply périodique (en blocs, pas une à une) à partir d’un journal distant (rien de plus).

Nous ne prétendons pas qu’une telle évolution continuerait à se manifester avec des rythmes de dépôt encore plus élevés côté source. Et il serait vain d’espérer que, si des dizaines de milliers de jobs interactifs effectuaient des changements de bases de données à une très forte cadence côté source, un job apply unique pourrait suivre en permanence, côté cible. Si vous avez un trafic d’une telle densité, il vous faut un produit HA puissant. Le rafraîchissement périodique que je décris ici convient mieux à un site plus petit et plus modeste ne traitant qu’un jeu limité de fichiers critiques.

Téléchargez cette ressource

Guide de Sécurité IA et IoT

Guide de Sécurité IA et IoT

Compte tenu de l'ampleur des changements que l'IA est susceptible d'entraîner, les organisations doivent élaborer une stratégie pour se préparer à adopter et à sécuriser l'IA. Découvrez dans ce Livre blanc Kaspersky quatre stratégies efficaces pour sécuriser l'IA et l'IoT.

Tech - Par Renaud ROSSET - Publié le 24 juin 2010