> Tech > Les bases des performances du stockage

Les bases des performances du stockage

Tech - Par Renaud ROSSET - Publié le 24 juin 2010
email

La figure 1 illustre le temps de réponse d'un disque normal. Au fur et à  mesure que le nombre de requêtes adressées au disque augmente, le temps de réponse augmente lui aussi en suivant une courbe exponentielle.
C'est la mise en file d'attente du disque qui provoque ce comportement

et il n’y
a pas grand-chose à  faire. Un disque ne peut prendre en charge qu’un nombre limité
d’E/S et les files d’attente des E/S s’accumulent une fois que le disque atteint
cette limite. De plus, normalement, plus le disque est grand, plus il est lent.
Par exemple, il ne faut pas s’attendre à  ce qu’un disque de 50 Go traite plus
de 70 requêtes d’E/S par seconde.

Au fil du temps, les disques peuvent tourner plus vite, se densifier et contenir
davantage de données, mais ils ne peuvent malgré tout prendre en charge les E/S
qu’à  une vitesse définie et cette vitesse n’augmente pas.
Les transactions appliquées par l’ESE aux bases de données Exchange Server utilisent
un processus de commit à  deux phases, garantissant que toutes les modifications
de bases de données faisant partie d’une transaction ont bel et bien lieu. Une
transaction modifie des pages de bases de données au fur et à  mesure de son déroulement
et c’est le buffer du journal de transactions qui stocke les changements.
Pour garantir l’intégrité de la base de données, une zone spéciale de la mémoire
baptisée Version Store contient le contenu original des pages. Lorsque la transaction
s’exécute, le moteur de la base de données transfère les changements de pages
des buffers des journaux de transactions dans les fichiers journaux des transactions,
puis supprime les pages du Version Store.
Si l’ESE doit arrêter la transaction, tous les changements la concernant seront
transférés en sens inverse. L’enregistrement dans le journal de transactions est
la partie cruciale du processus en matière de performances. L’IS ordonne les pages
dans la mémoire et les exécute avec un procédé multithread efficace, mais les
enregistrements dans le journal de transactions sont séquentiels. Si le disque
contenant les journaux ne répond pas, il se produira un retard et Exchange Server
ne consignera pas rapidement les transactions.
C’est pourquoi, il faut s’assurer que le chemin des E/S au disque contenant les
journaux de transactions est aussi efficace que possible. Notez que les mêmes
caractéristiques de performances se manifestent dans AD, qui utilise une version
modifiée de l’ESE. Pour des performances optimales, placez les journaux de transactions
dans le volume le plus réactif ou affichant des performances d’écriture optimalesPour
des performances optimales, il faut placer les journaux de transactions dans le
volume le plus réactif ou le périphérique affichant des performances d’écriture
optimales.

Le but est de parvenir à  ce que Exchange Server écrive le plus vite possible les
transactions dans les fichiers journaux. L’approche habituelle – et la bonne –
consiste à  placer les fichiers journaux sur un disque distinct de celui qui contient
la base de données. Pour garantir la fiabilité des données, les journaux et la
base de données doivent être séparés. N’oublions pas qu’une base de données opérationnelle
n’est jamais complètement à  jour. Les journaux de transactions contiennent des
transactions qui n’ont peut-être pas encore été exécutées par l’IS.

C’est pourquoi, si le disque contenant la base de données tombe en panne, il faut
recréer la base de données (en restaurant la sauvegarde complète la plus récente)
et faire refaire par Exchange Server les transactions restantes à  partir des journaux
créés par les utilisateurs depuis la sauvegarde. Bref, si les journaux de transactions
et la base de données résident sur le même disque, il y aura de gros problèmes
en cas de défaillance.

Pour garantir la fiabilité, mettez en miroir le disque des journaux de transactions.
N’utilisez pas le RAID 5 sur le volume hébergeant les journaux de transactions,
parce qu’il ralentit les opérations d’écriture dans les journaux et dégrade les
performances globales des systèmes. (Pour en savoir plus sur le RAID 5, voir l’encadré
 » Pourquoi le RAID 5 est-il si lent en écriture ? « ). Le RAID 0+1 (c’est-à -dire
l’entrelacement et la mise en miroir) assure les meilleures performances d’écriture
pour les gros volumes et est extrêmement tolérant aux pannes. Il revient toutefois
généralement trop cher en termes d’allocation de disques aux journaux de transactions.

Le choix habituel pour les volumes hébergeant les journaux de transactions est
le RAID 1 (c’est-à -dire la mise en miroir), qui assure un niveau de protection
adéquat équilibré avec de bonnes performances d’E/S. N’utilisez jamais le RAID
0 pour un disque contenant les journaux de transactions : en cas de défaillance
d’un disque, vous courez le risque de perdre des données. Chaque groupe de stockage
utilise un jeu de journaux de transactions séparé. Il faut les séparer le plus
efficacement possible sur plusieurs volumes mis en miroir.

Or une grappe de stockage ne peut supporter qu’un nombre limité d’unités logiques,
et il peut être nécessaire de faire quelques compromis. Sur les petits serveurs,
il est possible de combiner des jeux de journaux de différents groupes de stockage
sur un seul volume. Cette approche réduit la quantité de stockage nécessaire au
serveur, mais avec l’inconvénient de placer tous les oeufs dans le même panier.

Une erreur se produisant sur le volume affecte tous les jeux de journaux ; obligeant
à  mettre hors ligne chaque groupe de stockage. Les caractéristiques des E/S des
bases de données Exchange Server présentent un accès sélectif à  travers tout le
fichier de la base de données. L’IS utilise des threads parallèles pour mettre
à  jour les pages de la base de données, c’est pourquoi un volume multidisque aide
à  prendre en charge plusieurs requêtes simultanées de lecture et écriture. En
fait, la capacité du système à  traiter des requêtes multithreads augmente au fur
et à  mesure que l’on ajoute des disques à  un volume.Depuis les débuts d’Exchange
Server, la plupart des concepteurs de systèmes ont recommandé une protection RAID
5 pour les bases de donnéesDepuis les débuts d’Exchange Server, la plupart des
concepteurs de systèmes ont recommandé une protection RAID 5 pour les bases de
données. Le RAID 5 est un bon compromis pour protéger le stockage et fournir des
performances de lecture et d’écriture raisonnables sans utiliser trop de disques.

Mais étant donné le faible coût des disques et la nécessité de pousser les performances
des E/S, beaucoup d’implémentations Exchange Server 5.5 haut de gamme utilisent
à  présent des volumes RAID 0+1 pour héberger les bases de données. Une tendance
qui ne va pas s’arrêter en 2000. Bien que l’on puisse à  présent partitionner les
E/S entre plusieurs bases de données, le nombre de boîtes à  lettres supportées
par un serveur individuel va probablement augmenter, poussant ainsi le total des
E/S générées. Les grands clusters Exchange 2000 à  4 voies devront supporter jusqu’à 
10.000 boîtes à  lettres et gérer de 200 à  400 Go de bases de données entre plusieurs
groupes de stockage.

En termes d’opérations d’écriture, l’exécution du RAID 0+1 va deux fois plus vite
que celle du RAID 5, et un grand serveur Exchange 2000 devra donc déployer cette
configuration pour la protection des bases de données. Pour donner les meilleures
performances d’écritures, à  la fois dans les journaux de transactions et dans
les bases de données, il faut utiliser le cache d’écriture du contrôleur de stockage,
mais seulement à  condition d’avoir convenablement protégé ses données contre tout
risque de panne et de perte. Il faut mettre le cache en miroir et le secourir
par batterie pour le protéger contre les pannes de courant. Il faut aussi pouvoir
le transférer entre les contrôleurs pour permettre, le cas échéant, de changer
un contrôleur.
Les opérations de lecture pour accéder aux messages et aux fichiers attachés de
la base de données récupèrent habituellement des informations dans toute l’étendue
du fichier, ce qui ne rend pas le cache de lecture du contrôleur très favorable
aux performances.
L’ESE effectue la mise en antémémoire au niveau des applications. N’essayez pas
de combiner trop de disques dans un volume RAID 5. Chaque fois qu’une panne survient,
c’est la totalité du volume qui doit se recréer. La durée de cette reconstruction
est directement proportionnelle au nombre et à  la taille des disques du volume
et chaque disque ajouté augmente donc cette durée. La plupart du temps la recréation
des volumes s’effectue en tâche de fond et le volume reste en ligne. Mais en cas
de survenue de nouvelle panne pendant la reconstruction, il pourrait y avoir une
perte de données.

C’est pourquoi, il est bon de réduire la durée de la reconstruction en diminuant
le nombre de disques de l’agrégat de partitions. Décider le nombre précis de disques
à  mettre dans un volume revient à  un équilibrage entre la taille du volume à  créer,
la durée des reconstructions prévue, les données qu’il s’agit de stocker sur le
volume et le temps moyen prévu entre les pannes.
S’il s’agit de stocker des données non essentielles sur un grand volume par souci
de commodité, il est possible de combiner beaucoup de disques dans le volume.

Mais une base de données Exchange Server tend à  être sensible aux pannes. Je conseille
la plus grande prudence en ne plaçant pas plus de douze disques dans le volume.L’examen
des E/S des serveurs Exchange 2000 révèle certains points intéressants, dont certains
diffèrent significativement des modèles Exchange 5.5L’examen du modèle des E/S
des serveurs Exchange 2000 révèle certains points intéressants, dont certains
diffèrent significativement des modèles Exchange 5.5. La base de données déroulante
donne des performances éblouissantes aux clients IMAP4, POP3 et HTTP, en leur
permettant de stocker ou de récupérer des données beaucoup plus vite de la base
de données déroulante que de la traditionnelle EDB (Exchange Database).
Les clients accèdent à  la base de données déroulante grâce à  un pilote filtre
en mode kernel baptisé ExIFS (Exchange Server Installable File System). Comme
l’EDB, l’ExIFS traite les données en pages de 4Ko, mais il peut allouer des pages
et y accéder de manière contiguà«, alors que l’EDB se contente de demander des
pages à  ESE et risque de recevoir des pages éparpillées entre des fichiers.
Les petits fichiers ne montreront pas des performances particulières, en revanche,
il suffit d’imaginer la quantité de travail nécessaire pour accéder à  un grand
fichier attaché à  partir d’une série de pages de 4 Ko, que l’IS a besoin d’extraire
de plusieurs emplacements. Comme son accès est contigu, la base de données en
continu donne des performances nettement meilleures pour les grands fichiers.

Qui plus est, l’accès à  un disque contigu transfère bien plus de données (jusqu’à 
64 Ko par E/S) ; c’est pourquoi pour obtenir les performances désirées, le sous-système
de stockage doit pouvoir traiter de telles exigences. Les avancées dans la technologie
du stockage focalisent souvent sur la quantité de données pouvant résider sur
un système physique.

Au fur et à  mesure que nous évoluons vers la consolidation des petits serveurs
en clusters plus grands, les performances d’E/S deviennent essentielles. Les concepteurs
de systèmes doivent donc concentrer leurs efforts sur l’intégration de nouvelles
technologies permettant aux E/S d’atteindre plus vite la CPU. Exchange 2000 est
la première application horizontale à  tirer pleinement profit du protocole fibre
channel, qui délivre des taux de transfert allant jusqu’à  100 Mbps. Les systèmes
supportant des milliers d’utilisateurs doivent gérer de grandes quantités de données.

La capacité de stocker et de gérer des données n’est pas nouvelle, mais les avancées
comme le fibre channel permettent à  présent aux configurations systèmes d’atteindre
un meilleur équilibre entre la CPU, la mémoire et le stockage.

Téléchargez cette ressource

Guide de Sécurité IA et IoT

Guide de Sécurité IA et IoT

Compte tenu de l'ampleur des changements que l'IA est susceptible d'entraîner, les organisations doivent élaborer une stratégie pour se préparer à adopter et à sécuriser l'IA. Découvrez dans ce Livre blanc Kaspersky quatre stratégies efficaces pour sécuriser l'IA et l'IoT.

Tech - Par Renaud ROSSET - Publié le 24 juin 2010