Pourquoi n'est-il pas recommandé d'utiliser RAID 5 pour un fichier journal?
En lisant SQL Server Query Performance Tuning écrit par Grant Fritchey, j'ai eu du mal à comprendre la partie suivante: évitez RAID 5 pour les t-logs car , pour chaque demande d'écriture, les baies de disques RAID 5 entraînent deux fois plus d'E/S disque que RAID 1 ou RAID 10.
Je sais que RAID 5 se différencie des autres RAID par sa fonction de parité. Cela signifie que si certains disques tombent en panne, il est possible de récupérer les données perdues des autres disques. Je veux comprendre pourquoi il n'est pas recommandé d'utiliser RAID 5 pour un fichier journal des transactions. L'explication dans le livre ne m'a pas suffi pour l'obtenir. Peut-être que quelqu'un pourrait me l'expliquer ou fournir un bon article.
Les écritures du journal des transactions, lorsqu'elles se produisent, sont des opérations synchrones, c'est-à-dire que l'activité qui a provoqué une écriture de journal doit attendre la fin des E/S du journal avant de continuer à faire ce qu'elle fait. Par conséquent, les écritures de journal sont très sensibles au débit d'écriture du stockage sous-jacent.
Comme vous l'avez mentionné, chaque écriture sur un périphérique RAID-5 a une surcharge1 de calculer et d'écrire un bloc de parité en plus du ou des bloc (s) de données. Aussi petit soit-il, ce travail supplémentaire que RAID-5 effectue sur chaque opération d'écriture est la raison derrière la recommandation de ne pas utiliser RAID-5 pour le stockage des journaux.
1 - Plus de détails dans ce Q&A
RAID-5 maintient la redondance en utilisant N-1 disques pour les données et 1 disque pour les XOR de ces données. (Ce n'est pas en fait le même disque utilisé pour toute la parité; c'est RAID-4. RAID-5 distribue la parité sur tous les disques, changeant à chaque limite de "bande".) https://en.wikipedia.org/wiki/Standard_RAID_levels#RAID_5
La plus grande surcharge d'écriture RAID-5 (lecture + réécriture du disque de parité pour ce bloc) s'applique uniquement aux écritures courtes. Une écriture pleine bande (par exemple dans le cadre d'une grande E/S séquentielle sans synchronisation/vidage après de petites étapes) peut simplement calculer la bande de parité à partir des bandes de données et les écrire toutes en parallèle, sans avoir à lire quoi que ce soit à partir du disque.
Comme le souligne mustaccio, les écritures du journal des transactions doivent atteindre le disque avant que nous puissions autoriser les écritures ultérieures à atteindre le disque. (Ou au moins la mémoire sauvegardée par batterie d'un contrôleur RAID. C'est à dire devenir persistante.) Cela signifie généralement qu'ils ne peuvent pas être mis en mémoire tampon dans une grande écriture pleine bande contiguë.
Dans le cas optimal, N-disque RAID-5 séquentiel la bande passante d'écriture est en théorie égale au temps de bande passante par disque N-1. (Plus un peu de temps CPU, ou même pas si le calcul de parité XOR est déchargé sur un contrôleur RAID matériel.)
Dans le cas pessimal, oui, RAID-5 doit faire des E/S de disque supplémentaires pour lire les anciennes données et parité et les mettre à jour en XOR les anciennes données dans la parité (pour les supprimer), puis XORing dans les nouvelles données.
Notez que ce n'est pas seulement le calcul la parité qui ajoute la grosse surcharge. C'est que les données dont vous avez besoin pour calculer la nouvelle parité peuvent être stockées sur le disque, pas en mémoire, pour les petites écritures.
Le RAID-5 est (très) mauvais pour les petites écritures, très bon pour les grandes écritures (presque aussi bon que le RAID-0) et bon pour les lectures en général.
Historiquement, certains contrôleurs RAID liraient toute la longueur d'une bande pour mettre à jour la parité, mais au moins le logiciel RAID Linux ne lit que les secteurs qui correspondent à la petite écriture réelle. Cela aide certains, mais une taille de bande petite comme 32k ou 64k (je pense) est généralement une bonne chose (les écritures pleine bande sont donc plus courantes sans avoir à mettre en mémoire tampon des mégaoctets de données).
Pourtant, cela va de "très très mauvais" à "très mauvais" par rapport à RAID10 ou RAID1 où de petites écritures peuvent simplement se produire sur les deux disques qui contiennent les blocs en cours d'écriture.