Ce document compare deux scénarios de répartition des transactions sur plusieurs serveurs SQL, en évaluant une configuration actuelle en cluster versus une approche utilisant GridScale. Le scénario avec GridScale permet une répartition de charge plus équilibrée, ce qui réduit la surcharge sur les serveurs lors d'événements de forte demande. Le scénario #2 offre une meilleure gestion des surcharges grâce à la possibilité d'ajouter rapidement des serveurs.

1. Simulation de performance Répartition des transactions sur plusieurs serveurs SQL depuis un serveur GridScale versus la situation actuelle.

2. Évaluation de 2 scénarios Scénario #1 : Utilisation de 3 machines en cluster avec une instance par machine. Ce scénarios est actuellement en place. Scénario #2 : Utilisation de GridScale pour répartir la charge sur les 3 machines.

3. Charge normale actuel 1000 EXT 500 MIX 200 INT TPS Transaction par seconde Instances

4. Charge maximale Hypothèse : maximum de 8000 TPS par machine. NOTE : Pour être capable d’évaluer le max, il faudrait stresser les serveurs jusqu’au point de faille.

5. Charge normale évaluée 13% 6% 3% Charge % 8000 8000 8000 TPS Max 1000 EXT 500 MIX 200 INT TPS Instances

6. Facteur de charge lors d’un évenement Lorsqu’un évenement arrive, quel sera l’accroissement de la charge ? Hypothèse : Disons que la charge sera 10 fois plus grande.

7. Surcharge évaluée 125% 63% 25% Charge % 8000 8000 8000 TPS Max 10000 EXT 5000 MIX 2000 INT TPS x 10 Instances

8. Le serveur en surcharge Comme vous pouvez constater, le serveur EXT est en surcharge (125%) lors d’un évenement et les 2 autres sont capable de respirer encore.

9. Calculs avec la répartition de charge selon le scénario #2 Toutes les transactions sont réparties aux trois serveurs. GridScale balance les lectures sur un serveur mais transmet les écritures sur tous les serveurs. Hypothèse : 10% des transactions sont des écritures et 90% sont des lectures seulement. En surcharge, les serveurs ont 17000 transactions à la secondes dont : 1700 écritures et 15300 lectures. Donc chaque serveur reçois les 1700 écritures et seulement un tier des 15300 lectures. Donc 5100 lectures. Ce qui fait que les serveurs reçoivent tous : 1700 + 5100 = 6800 TPS Note : avec une répartition 20%, 80% = 7934 TPS

10. Surcharge évaluée 85% 85% 85% Charge % 8000 8000 8000 TPS Max 6800 EXT 6800 MIX 6800 INT TPS Instances

11. Ajout de noeuds Vu le fait que GridScale répartit la charge sur les 3 serveurs, aucun serveur n’a subit d’arrêt de service. Si on constate que la surcharge est constante ou qu’un évenement est prévu, il est possible d’ajouter un serveur rapidement. Voyont ce qu’il se passerait dans ce cas.

12. Surcharge répartie sur 4 noeuds 69% 5525 8000 EXT 69% 69% 69% Charge % 8000 8000 8000 TPS Max 5525 NEW 5525 MIX 5525 INT TPS Instances

13. Conclusion Le scénario #1 pourrait probablement passer l’épisode de surcharge temporaire en ajoutant de la mémoire et un CPU. Ceci permettrait d’augmenter la capacité maximal en TPS mais le problème reviendra plus tard. L’avantage du scénario #2 est d’augmenter le contrôle lors des épisodes de surcharges.

14. Questions ?