Simulation de performance Répartition des transactions sur plusieurs serveurs SQL depuis un serveur GridScale versus la si...
Évaluation de 2 scénarios <ul><li>Scénario #1 : Utilisation de 3 machines en cluster avec une instance par machine. Ce scé...
Charge normale actuel 1000 EXT 500 MIX 200 INT TPS Transaction par seconde Instances
Charge maximale <ul><li>Hypothèse : maximum de 8000 TPS par machine. </li></ul><ul><li>NOTE : Pour être capable d’évaluer ...
Charge normale évaluée 13% 6% 3% Charge % 8000 8000 8000 TPS Max 1000 EXT 500 MIX 200 INT TPS Instances
Facteur de charge lors d’un évenement <ul><li>Lorsqu’un évenement arrive, quel sera l’accroissement de la charge ? </li></...
Surcharge évaluée 125% 63% 25% Charge % 8000 8000 8000 TPS Max 10000 EXT 5000 MIX 2000 INT TPS x 10 Instances
Le serveur en surcharge <ul><li>Comme vous pouvez constater, le serveur EXT est en surcharge (125%) lors d’un évenement et...
Calculs avec la répartition de charge selon le scénario #2 <ul><li>Toutes les transactions sont réparties aux trois serveu...
Surcharge évaluée 85% 85% 85% Charge % 8000 8000 8000 TPS Max 6800 EXT 6800 MIX 6800 INT TPS Instances
Ajout de noeuds <ul><li>Vu le fait que GridScale répartit la charge sur les 3 serveurs, aucun serveur n’a subit d’arrêt de...
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 T...
Conclusion <ul><li>Le scénario #1 pourrait probablement passer l’épisode de surcharge temporaire en ajoutant de la mémoire...
Questions ?
Prochain SlideShare
Chargement dans…5
×

Simulation De Performance

736 vues

Publié le

Voici une présentation sur comment la virtualisation permet de balancer le load sur plusieurs machines

Publié dans : Technologie
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Simulation De Performance

  1. 1. Simulation de performance Répartition des transactions sur plusieurs serveurs SQL depuis un serveur GridScale versus la situation actuelle.
  2. 2. Évaluation de 2 scénarios <ul><li>Scénario #1 : Utilisation de 3 machines en cluster avec une instance par machine. Ce scénarios est actuellement en place. </li></ul><ul><li>Scénario #2 : Utilisation de GridScale pour répartir la charge sur les 3 machines. </li></ul>
  3. 3. Charge normale actuel 1000 EXT 500 MIX 200 INT TPS Transaction par seconde Instances
  4. 4. Charge maximale <ul><li>Hypothèse : maximum de 8000 TPS par machine. </li></ul><ul><li>NOTE : Pour être capable d’évaluer le max, il faudrait stresser les serveurs jusqu’au point de faille. </li></ul>
  5. 5. Charge normale évaluée 13% 6% 3% Charge % 8000 8000 8000 TPS Max 1000 EXT 500 MIX 200 INT TPS Instances
  6. 6. Facteur de charge lors d’un évenement <ul><li>Lorsqu’un évenement arrive, quel sera l’accroissement de la charge ? </li></ul><ul><li>Hypothèse : Disons que la charge sera 10 fois plus grande. </li></ul>
  7. 7. Surcharge évaluée 125% 63% 25% Charge % 8000 8000 8000 TPS Max 10000 EXT 5000 MIX 2000 INT TPS x 10 Instances
  8. 8. Le serveur en surcharge <ul><li>Comme vous pouvez constater, le serveur EXT est en surcharge (125%) lors d’un évenement et les 2 autres sont capable de respirer encore. </li></ul>
  9. 9. Calculs avec la répartition de charge selon le scénario #2 <ul><li>Toutes les transactions sont réparties aux trois serveurs. </li></ul><ul><li>GridScale balance les lectures sur un serveur mais transmet les écritures sur tous les serveurs. </li></ul><ul><li>Hypothèse : 10% des transactions sont des écritures et 90% sont des lectures seulement. </li></ul><ul><li>En surcharge, les serveurs ont 17000 transactions à la secondes dont : 1700 écritures et 15300 lectures. </li></ul><ul><li>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 : </li></ul><ul><li>1700 + 5100 = 6800 TPS </li></ul><ul><li>Note : avec une répartition 20%, 80% = 7934 TPS </li></ul>
  10. 10. Surcharge évaluée 85% 85% 85% Charge % 8000 8000 8000 TPS Max 6800 EXT 6800 MIX 6800 INT TPS Instances
  11. 11. Ajout de noeuds <ul><li>Vu le fait que GridScale répartit la charge sur les 3 serveurs, aucun serveur n’a subit d’arrêt de service. </li></ul><ul><li>Si on constate que la surcharge est constante ou qu’un évenement est prévu, il est possible d’ajouter un serveur rapidement. </li></ul><ul><li>Voyont ce qu’il se passerait dans ce cas. </li></ul>
  12. 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. 13. Conclusion <ul><li>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. </li></ul><ul><li>L’avantage du scénario #2 est d’augmenter le contrôle lors des épisodes de surcharges. </li></ul>
  14. 14. Questions ?

×