Il y a quelques années, une grande compagnie d’assurances ne parvenait pas à respecter ses SLA de performances pour certaines de ses applications essentielles. Le VP chargé des infrastructures a réclamé des millions pour remplacer les systèmes existants par des baies modernes entièrement flash. Au bout de plusieurs mois d’installation du nouveau matériel et de migration des données, l’équipe enregistra bien quelques améliorations minimes des performances mais, à l’évidence, la technologie flash n’avait pas résolu le problème.

La raison était simple : le débit en lecture/écriture des supports de stockage n’est qu’un des composants du système et, bien souvent, ce n’est pas lui qui contribue le plus aux performances.

Lorsque vous faites votre premier véritable investissement dans un bon système audio (amplificateur Carver avec enceintes de studio B&W 801), on apprend que les performances d’un système ne sont jamais que celles de son plus mauvais composant. Autrement dit, si vous avez un super ampli, d’excellents moniteurs, des câbles plaqués or et un enregistrement fantastique, mais que vous écoutez tout ça sur un lecteur de cassettes bon marché, il y a peu de chances pour que le son soit bon.

C’est la même chose pour les applications. Les bases de données sont au cœur de la plupart d’entre elles. L’analyse des profils de temps d’attente montre qu’il est effectivement important d’optimiser les requêtes et d’ajouter des index pour éviter les contentions de ressources serveur et la transformation des supports de stockage en goulot d’étranglement. Mais elle montre aussi que dans une grande partie des cas, le ralentissement est surtout dû aux I/O.

Bien sûr, chaque situation est unique et le profil de performances dépend d’un grand nombre de facteurs, qui peuvent varier au fil du temps en fonction de la charge et d’autres éléments.

La meilleure pratique consiste à utiliser des outils de suivi pour connaître le profil de performances de chaque élément du système et déterminer les actions qui auront vraiment une influence.

L’investissement dans du stockage flash comme unique solution aux problèmes de performances est un leurre. Cela revient à jeter l’argent par les fenêtres. En reprenant l’exemple précédent, c’est comme remplacer des moniteurs de bonne qualité par des modèles encore meilleurs alors que le problème vient de la source audio (un lecteur de cassettes), dont le rapport signal/bruit est désastreux et qui ne pourra jamais produire un son de bonne qualité, quel que soit le prix que vous mettrez dans les haut-parleurs.

L’enquête que nous venons de publier montre que 17 % des services informatiques ont investi dans des baies tout-flash (AFA), sans pour autant parvenir à atteindre les performances promises. Je suis certain qu’un grand nombre des 83 % restants ont vu s’améliorer les performances. Mais je me demande aussi combien ont réellement résolu le problème et combien ont enregistré le ROI qu’ils attendaient de leurs investissements.

Soyons clairs, nous n’avons rien contre le flash. Les AFA, les NVMe et autres technologies sont fantastiques et aident indéniablement à accélérer les performances des systèmes IT. Simplement, il faut éviter d’y voir une panacée et qu’il est bon de se pencher sur d’autres solutions d’amélioration des performances, en cherchant à comprendre les avantages qu’elles apportent.

Faire sauter le goulot d’étranglement des E/S

Nous savons que les goulots d’étranglement dus aux I/O figurent parmi les problèmes les plus courants des bases de données et du stockage. Tandis que les processeurs gagnaient en puissance et que les systèmes de stockage et la connectivité des réseaux s’accéléraient, les I/O sont en général restées au stade de la connexion en série reliant les serveurs et les supports de stockage.

« La première contrainte qui apparaît lorsque l’on cherche la cause des problèmes de performances de MySQL, on la trouve au niveau des I/O. C’est la cause principale des mauvaises expériences utilisateur. J’ai vérifié après avoir griffonné quelques statistiques sur un coin de table et il semble qu’en effet, les E/S représentent 75 % des attentes pour une même instance MySQL » a dit Robert Mandeville, un grand manitou des performances de bases de données.

C’est là que la technologie Parallel I/O peut tout changer. Elle a été créée il y a plus de 10 ans par un groupe d’ingénieurs d’une incroyable intelligence qui résolvaient des problèmes d’I/O dans des systèmes en temps réel hyper efficaces pour des systèmes de stockage d’entreprise. Parallel I/O utilise au maximum les processeurs multicœurs et diminue ainsi la latence de façon spectaculaire. Elle utilise en outre des systèmes de cache assisté par IA et d’autres techniques développées pendant plus de 20 ans pour optimiser les débits.

Il semble que chaque fournisseur de ce marché se targue d’offrir des performances élevées, ce qui ne veut pas dire grand-chose. C’est pour cela que nous avons des bancs d’essais. Parallel I/O a établi le record SPC-1 du secteur avec un temps de réponse 363 % plus rapide que son suivant immédiat, une baie entièrement flash. Certains services informatiques signalent une multiplication des performances par 5, ce qui paraît tout bonnement incroyable jusqu’à ce que vous le constatiez par vous-même.

L’optimisation des I/O vient compléter des systèmes de stockage plus rapides. Elle peut accélérer des baies plus anciennes, prolonger leur durée de vie et offrir le plus haut niveau d’IOPS possible pour une baie NVMe (bien que la technologie NVMe utilise une certaine forme de parallélisation). N’hésitez pas à consulter ce rapport d’IDC sur l’utilisation de Parallel I/O pour accélérer les infrastructures hyperconvergées.

 

Avec DBLAT, on peut faire beaucoup avec un peu de flash

Imaginons que vous ayez identifié votre support de stockage comme étant le goulot d’étranglement de vos systèmes et qu’investir dans des AFA soit la solution idoine à vos problèmes de performances. À coup sûr, votre fournisseur de stockage vous conseillera sans sourciller de remplacer tout votre stockage par ses baies AFA flambant neuves. Or, cela pose un certain nombre de problèmes :

  1. Cela peut coûter très cher
  2. Vous pouvez être contraint de faire migrer toutes vos données vers les nouvelles baies de stockage
  3. Vous ne rentabiliserez plus du tout vos baies actuelles
  4. Dans quelques années, lorsqu’une autre technologie « de rupture » apparaîtra, probablement proposée par un autre fournisseur, allez-vous à nouveau tout remplacer ?
  5. Vous jouez tout votre avenir sur un seul fournisseur. Ils aiment bien vous garder captif aussi longtemps que vous les y autorisez.

 

Vous pouvez aussi décider d’acheter « un peu de flash », c’est-à-dire une seule baie hautes performances. Vous devrez alors choisir les applications qui auront droit à la technologie la plus rapide et celles qui devront se contenter de systèmes moins performants. Dans la plupart des cas, le choix se fait en fonction de celui qui proteste le plus fort, ce qui ne semble pas être la meilleure approche.

Il y a un meilleur moyen.

Dynamic Block-Level Auto-Tiering (DBLAT) est un système super intelligent qui utilise la technologie flash de la façon la plus efficace. Il permet d’obtenir des gains de performances considérables pour toutes les applications à partir d’un investissement minime en flash.

DBLAT (acronyme entièrement inventé pour que cela est l’air cool) est une fonctionnalité de DataCore Software-defined Storage (SDS) qui installe une couche logicielle intelligente sur l’ensemble de vos systèmes de stockage. Elle fait abstraction de la diversité des fournisseurs, des types de stockage et des configurations pour créer des pools de stockage virtuels. Une fois SDS installé, vous n’aurez plus jamais à effectuer de migration, puisque le logiciel déplace les données en fonction des besoins.

La hiérarchisation automatique (Auto Tiering) déplace les données vers le système de stockage le plus performant en fonction du profil de performances constaté pour chaque application. Combinée avec SDS, elle vous permet d’effectuer cette opération sur des matériels de différents fournisseurs. Vous pouvez donc ajouter une baie tout-flash et le système y déplacera automatiquement les applications qui nécessitent les performances les plus élevées.

Lorsqu’elle est dynamique, la hiérarchisation automatique exécute cette optimisation en continu. Elle s’appuie pour cela sur l’apprentissage machine pour observer les requêtes et les besoins de performances et apporte les ajustements nécessaires. Les choses deviennent encore plus intéressantes lorsque la hiérarchisation automatique intervient au niveau des blocs.

Imaginez que vous ajoutiez un petit stockage NVMe connecté en direct au serveur qui exécute votre plateforme SDS. SDS n’identifie alors pas les pools, les applications ou les LUN qui ont besoin de cette hiérarchisation automatique, mais les blocs de données qui en ont besoin et les déplace tout simplement vers la baie NVMe.

Imaginons que vous ayez une base de données contenant des millions de produits, mais que 5 % seulement d’entre eux soient très populaires. Le système ne déplacera vers le stockage NVMe que les blocs sur lesquels ces produits sont enregistrés afin que leur accès soit ultra rapide. Les articles du catalogue plus rarement demandés seront conservés sur la baie de stockage plus lente. Cela libère le stockage NVMe et rend d’autres blocs disponibles pour d’autres applications.

Imaginez maintenant que cette solution soit combinée avec la mise en cache dynamique intelligente, Parallel I/O, la planification optimisée des requêtes et d’autres technologies brevetées. Mieux encore, imaginez que tout cela se produise automatiquement, sur l’ensemble de vos systèmes de stockage, quel que soit leur âge, et soit inclus dans toutes les licences SDS sans coût supplémentaire (ces licences étant en outre perpétuelles).

La hiérarchisation automatique est une technologie capable d’améliorer les performances de la quasi-totalité des systèmes informatiques qui utilisent des types de systèmes de stockage différents. Surtout, elle peut vous aider à améliorer considérablement vos performances avec un investissement relativement réduit.  En savoir plus sur la hiérarchisation automatique ici.

The post Rechercher la réponse aux problèmes de performances au mauvais endroit appeared first on DataCore Software.

Consulter la source originale