Paramètres RAID avancés
Le principe du RAID consiste à découper les fichiers en petits morceaux afin de les répartir sur les différents disques durs composant une pile RAID. On parle alors de chunk, stripe, bloc size, etc…. Beaucoup de confusion règne autour de ces termes, et chacun s’approprie sa propre définition. Voici de quoi voir plus clair 😉
Voici une définition de ces termes:
- Spindle: disque dur
- Secteur (ou unité d’allocation): ensemble d’octets
- Bloc: ensemble de secteurs
- chunk: équivalent au bloc dans le monde RAID
- Stripe (ou stripe unit): certains l’assimile à un bloc ou chunk sur un même spindle
- Stripe Width (largueur de bande): nombre de disques composants une pile RAID
- Stripe Size (taille de bande): certains l’assimilent à un ensemble de chunks (ou blocs) sur un même disque ou répartis sur plusieurs disques (nous allons retenir cette dernière définition)
Le chunk correspond à la taille des données contigües qui sont écrites sur un disque dur avant que le contrôleur RAID ne passe à un autre disque dans la bande.
Notez également que si vous comptez utiliser une taille relativement petite, prenez le soin de bien choisir votre contrôleur (doté d’un processeur ASIC puissant) car celui-ci va être très sollicité pour découper les données. Pour définir correctement votre paramètre chunk, faîtes correspondre votre Pattern I/O à la taille du chunk, dans la mesure du possible.
La taille de la bande (stripe size) définit la taille d’un bloc (ou chunk) dont les secteurs sont répartis sur plusieurs disques. Par exemple, un fichier de 1M représentera seize blocs sur un RAID dont le stripe size est de 64k. A l’inverse, si le fichier est inférieur à la taille de la bande, le contrôleur RAID enverra la donnée sur un seul disque ne sachant pas la découper, entrainera l’occupation de la bande et une baisse de performance.
Prenons un exemple, une base de données lit ou écrit en une opération de petites données contenues dans les tables, comme des numéros de carte de crédit, des coordonnées de clients, … Une taille de 64k parait surdimensionné, car il est rare qu’une coordonnée pèse 60k, de plus l’espace réservé de 64k ne sera pas consommé, d’où une perte de performances et d’espace disque.
Tandis que pour des opérations de serveurs de fichiers, il convient d’envoyer le maximum de données en une opération, il convient alors de prendre une taille importante, 128k voire 256k, par exemple.
La taille de la bande s’obtient en multipliant le nombre de disques dans votre pile RAID (en capacité utile, c’est à dire un disque en moins dans votre calcul pour un RAID de niveau 5) par la taille de chunk, ou doit être un multiple de votre Pattern I/O.
Exemple: 32k de données sur un stripe de 8k = 4k de taille de chunk
Exemple: 1M de données sur un chunk de 64k = 16k de taille de stripe
Pour résumer, une petite taille favorisera les temps d’accès et les opérations d’entrée/sortie alors qu’une taille importante favorisera les débits de transfert.
Si vos accès sont en moyenne de 16k sur un stockage paramétré avec un chunk de 64k, les serveurs accéderont à un seul disque dans la pile RAID, ce qui n’est pas recommandé car le but est de répartir les données sur plusieurs disques afin d’en accélérer le traitement.
Dans l’exemple suivant, je compare un RAID composé de 4 disques durs, l’un avec un largueur de bande de 64 k, l’autre avec un largueur à 256k, avec des fichiers de tailles différentes. Le fichier de 128k est réparti sur l’ensemble des disques, et les autres fichiers sont également répartis sur l’ensemble des disques ne laissant que peu d’espace disque disponible.
Dans l’exemple ci-dessous, le fichier de 128k est stocké sur un disque seulement, celui de 256k sur deux disques et le fichier de 1M demeure sur quatre disques mais on constate que nous disposons de plus d’espace disque (disque dur 3 et 4).
Il est essentiel de retenir deux notions, les bases de données requièrent des opérations d’entrée/sortie par seconde très élevées tandis qu’un serveur de fichier requiert du débit. En règle générale, il convient de choisir une taille comprise entre 64 k et 1 M (nombreux gros chunks lus sur un même stripe) pour les accès séquentiels et 512B à 8 k pour les accès aléatoires.
Les schémas suivants comparent les débits en fonction de la taille du chunk et du Pattern I/O.
Ces tests démontrent que pour des bases de données (4 à 8k), la taille de chunk idéale est 32 ou 64k, tandis que pour des Pattern I/O « classique » (256 à 1M), la taille idéale du chunk est 128 ou 256k; et que pour les accès séquentiels intensifs la valeur idéale est 256 ou 512 et pour applications vidéo, streaming celle-ci est de 1024.
Ces tests ont été réalisés sur des accès séquentiels, pour des accès aléatoires, les conclusions tirées de l’analyse des schémas précédents s’appliquent également.
Vous avez constaté qu’il est important de tenir compte des paramètres abordés ici, sous peine de perdre inutilement de l’espace disque et d’obtenir des performances médiocres. Certaines baies analysent pour vous la taille de vos requêtes. Dans la capture suivante, la baie nous informe que les accès en lecture ont en moyenne une taille de 4k et 1M et 64k en écriture. On peut en déduire que cette baie de stockage héberge certainement une base de données, des fichiers de taille moyenne et importante.
Je travaille actuellement en tant qu’Enterprise Architect pour le groupe CAPGEMINI. Acteur et expert communautaire reconnu depuis de nombreuses années, j’anime ce site autour des technologies Microsoft, des thématiques du Cloud, des infrastructures, … Je suis également à l’origine de nombreuses publications dans la presse IT.