Avec la contribution de Jeffrey Slapp – Directeur de l’ingénierie des systèmes et de l’architecture solution, DataCore Software
Dernièrement, je me suis retrouvé dans plusieurs conversations qui traitaient de la parallélisation et de son importance, notamment pour le traitement des I/O. Dès que nous entendons le terme « Parallel I/O », nous avons tendance à nous interroger tout de suite sur les performances. S’il est certain que les performances liées aux charges de travail des applications sont améliorées dans le sens traditionnel (en termes de diminution de la latence, d’augmentation des opérations par seconde, etc.), l’histoire ne s’arrête pas là. En effet, une autre dimension entre en jeu.
Prenons un exemple de la vie courante qui nous permettra d’expliquer comment cela marche et pourquoi c’est important. Pour une question de simplicité, imaginons que nous nous trouvions aux caisses d’un supermarché et qu’il n’y ait qu’une seule caisse d’ouverte. Soixante clients sont en train de faire la queue, et chacun de ces 60 clients est susceptible d’avoir un nombre différent d’articles à payer, mais pour plus de simplicité, imaginons qu’ils en aient tous à peu près le même nombre. Si cela prend au caissier une minute pour prendre en charge chaque client, son taux de prise en charge est de : 1 client par minute. Jusqu’ici, c’est très simple.
À ce moment-là, le responsable du magasin se rend compte du bouchon que cela provoque et décide d’ouvrir cinq caisses supplémentaires, pour un total de six caisses. Avec six caisses désormais disponibles, six clients peuvent être pris en charge au même moment (c’est-à-dire en parallèle). Le nouveau taux de prise en charge passe à : 6 clients par minute.
Arrêtons-nous un instant. Je pense que personne ne pourra contester le fait que simplement en ouvrant plus de caisses, plus de clients peuvent être pris en charge en même temps. Mais l’autre aspect intéressant de ce système, c’est que l’attente effective totale pour tous les clients a également diminuée. Dans le premier scénario, où une seule caisse était ouverte, le délai total pour prendre en charge 60 clients était de 60 minutes. Dans le deuxième scénario, où six caisses étaient ouvertes, le délai total pour prendre en charge 60 clients était de 10 minutes. Vous voyez où je veux en venir. Imaginons maintenant qu’il y ait 60 caisses opérationnelles. Le nouveau taux de prise en charge effectif pour les 60 clients serait donc d’une minute. En effet, le responsable du magasin a réussi à faire correspondre la demande personnalisée des clients aux capacités des caisses du magasin.
Cet exemple est exactement ce qui se produit dans le monde de la technologie. Les charges de travail des applications sont les clients (générateurs d’I/O) attendant d’être servis, et le caissier et sa caisse sont le service (couche de réponse aux I/O). Le problème avec les systèmes actuels est qu’ils sont largement axés sur l’utilisation d’un seul « caissier » dans le processus de prise en charge.
Le traitement Parallel I/O fournit exactement ce qu’a fourni le responsable du magasin : plus de caissiers pour prendre en charge les clients en parallèle à mesure que la demande de charge de travail augmente.
Pour améliorer encore d’avantage l’expérience du client, imaginons que nous puissions rentrer dans le magasin, prendre nos articles et repartir immédiatement (tout en payant nos courses, évidemment), mais sans avoir à attendre dans la queue. Il faut bien entendu imaginer que le magasin dispose de tout ce dont vous aviez besoin, mais c’est le cas de la plupart des supermarchés. Ce n’est donc pas un problème. Le résultat est que le magasin peut désormais traiter beaucoup plus de clients qu’au départ et la satisfaction générale du client est alors élevée, car il ne doit plus attendre longtemps.
C’est un autre avantage de Parallel I/O, un mécanisme appelé anti-queue (en d’autres termes, ne faites la queue que si vous devez le faire). Adaptive Parallelization n’est pas seulement une innovation habile : c’est devenu un outil absolument indispensable si l’on veut gérer l’offensive très variable des I/O générés par les applications d’aujourd’hui. Mais la dimension supplémentaire des performances dont je parlais ci-dessus est la capacité à exécuter bien plus de fois le nombre d’applications simultanément à de meilleurs niveaux de performances que la seule application faisait autrefois. Si chaque charge de travail a son propre caissier (ou vendeur), vous pouvez exécuter bien plus d’applications (c’est-à-dire des bases de données, des machines virtuelles, etc.) et les exécuter plus rapidement, étant donné qu’il y a moins de demandes pour chaque caissier individuel.
En particulier avec les charges de travail hyperconvergées (HCI), le handicap causé par le traitement des I/O en travailleur unique est précisément ce qui empêche HCI d’atteindre des niveaux bien plus élevés de densité de charge de tra
vail par système. La couche de réponse aux I/O ne peut tout simplement pas répondre à la demande de charge de travail d’applications hautement simultanée. Et pour ne rien arranger, nous vivons désormais à « l’ère des conteneurs ». Dès lors, la simultanéité sera d’autant plus élevée, ce qui aggravera encore plus le bouchon de la couche de réponse aux I/O.
vail par système. La couche de réponse aux I/O ne peut tout simplement pas répondre à la demande de charge de travail d’applications hautement simultanée. Et pour ne rien arranger, nous vivons désormais à « l’ère des conteneurs ». Dès lors, la simultanéité sera d’autant plus élevée, ce qui aggravera encore plus le bouchon de la couche de réponse aux I/O.
