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
travail 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.
