Now Reading
Big Data et Cloud : minimisez vos temps d’IO
0

Big Data et Cloud : minimisez vos temps d’IO

by Cloud Guru2 juillet 2013

L’autre jour, j’écoutais à la radio une émission sur l’histoire du courrier et de la poste à travers les âges.  La journaliste expliquait comment les temps de transport s’étaient considérablement raccourcis au fil du temps. Au temps des relais postaux et des chevaux, cela prenait souvent plusieurs jours ou semaines pour acheminer une lettre en France et en Europe. Je ne parle même pas de voyages plus lointains ou les objets devaient traverser les océans. Le bateau était alors la seule option et l’échelle du temps était fort différente de ce que nous vivons aujourd’hui avec les avions modernes ! Cela prenait des semaines, voire des mois, pour les colis ou lettres pour achever leur voyage.article3_1

Avec l’arrivée de l’aviation et de nombreuses percées technologiques, ces temps de transport ont été drastiquement réduits.  Comparé aux semaines et aux mois nous pouvons dire qu’aujourd’hui un colis met une journée ou 2 pour parvenir à son destinataire. Les améliorations en termes de moyens de transport et dans les différentes organisations expliquent ce résultat.

Cette amélioration est encore plus importante dans le cadre des télécommunications. Les messages électroniques sont échangés par internet et à travers nos Smartphones en quelques secondes.

De nombreux secteurs au delà du système postal bénéficient de ces améliorations techniques pour réduire les temps d’attente. Par exemple dans l’industrie bancaire, les cartes de crédit ont permis de renforcer la sécurité et de réduire les temps de crédit/débit des comptes courants par rapport à une approche comme les chèques.

Économiser du temps est crucial dans notre monde moderne. Time is money !.

Quel est le parallèle sur ces temps de communication dans le Cloud ?

Dans le Cloud et le monde Internet, la vitesse est clé pour obtenir des réponses rapides. Ainsi comme pour le trafic postal, les architectures intelligentes adaptées au Cloud nécessitent des communications rapides. Au niveau d’un serveur ces communications vers le stockage s’appellent les entrées/sorties ou en anglais  input/output (I/O).  En fait nous avons besoin  de “nourrir” les processeurs avec les données des baies de stockage le plus rapidement  possible.

Dans la chaine de la performance, les 3 points  les plus importants sont :

  1. Le code applicatif
  2. Le processeur et la mémoire
  3. Les  I/O

Le code applicatif et la bonne utilisation des programmes en général est le facteur déterminant sur la performance globale de l’architecture. Il est sûr et certain qu’une amélioration dans le code aura un impact beaucoup plus important qu’une optimisation de processeur ou d’I/O.

Le processeur et la mémoire viennent en deuxième position quand le code est stabilisé. Le comportement correct de ces éléments dépend de la qualité du code fourni et du temps d’attente IO (le fameux I/O wait).  Ainsi comme dans le cas de notre colis, ce temps d’attente ralentira ou non de façon sensible l’occupation du processeur et aura un impact sur la performance globale de la chaîne.

article3_2Quid de Big Data dans le Cloud?

Il est clair que dans le domaine du Big Data, la quantité d’informations explose et la partie I/O devient de plus en plus critique.

 Toute avancée tangible dans des solutions techniques sera clé pour maitriser et  améliorer la performance. Tout « accélérateur d’I/O » sera le bienvenu !

De la même façon que nous avons défini différentes échelles de temps pour le transport postal, il nous faut définir des ordres de grandeur d’accès I/O suivant les technologies.

 Le temps du SAS

Les unités pour mesurer les temps d’accès sont la milliseconde (ms) et la microseconde (µs).

1 ms = 1000 µs.

Partons du principe que le processeur a besoin d’environ 100 µs pour initier la demande d’I/O et qu’il a de nouveau besoin de 100 µs pour interpréter cet I/O lors du retour de la baie de stockage.  Nous admettons aussi que les données se trouvent dans un stockage optimisé de type SAN  et que nous mesurons en moyenne le temps d’accès au disque (temps de service).

Il est clair que des temps de service supérieurs à 10 ms (10 000 µs) commence a poser des soucis aux applications. En pratique une baie avec des disques de type serial-attached SCSI (SAS) travaille autour d’un temps de service de 5ms (5 000 µs).

Résumons ces hypothèses dans un tableau :

Demande d’I/O par le processeur

Temps de service

Interprétation de l’I/O par le  processeur

Temps d’I/O total

Temps (µs)  SAS

100

5,000

100

5,200

Ces éléments sont mesurables au niveau :

  • Infrastructure  ( CPU et disks) : Administrateur système
  • Application : Administrator database

[…] Découvrez la suite et fin de cet article la semaine prochaine sur notre blog.

Philippe Lamarche
Philippe Lamarche est architecte avant vente dans la division hardware d’IBM. Après une douzaine d’années passées dans le design et conceptions de composants (processeurs, mémoires, ASICs) au centre IBM de Corbeil-Essonnes, il a rejoint la divison hardware (Systems Technology Group) en 1995. Après avoir occupé diverses positions d’avant vente technique sur la plateforme Power/AIX, il est aujourd’hui en charge de la définition d’architectures sur l’ensemble des composants des gammes IBM et plus particulièrement sur la partie PureFlex. A ce titre il travaille sur les gros projets Cloud IBM actuels incluant des Integrateurs majeurs du marché. Auteur de plusieurs « redbooks », il participe au blog IBM mondial « Thoughts on Smarter Computing ».

{lang: 'fr'}
About The Author
Cloud Guru

Vous souhaitez réagir sur cet article ?