Disques SATA qui gèrent correctement la mise en cache d'écriture?

15

Il est assez courant de voir des conseils pour désactiver le cache d'écriture sur les disques individuels utilisés pour les bases de données, sinon certains disques reconnaîtront les écritures qui n'ont pas encore atteint la surface du disque.

Cela implique que certains disques ne reconnaissent pas les écritures jusqu'à ce qu'ils soient parvenus à la surface du disque (mise à jour: ou qu'ils signalent avec précision lorsqu'ils sont invités à vider le cache. Où puis-je trouver de tels disques, ou où puis-je rechercher des informations faisant autorité sur où trouver ces disques?

Je configure des serveurs de base de données qui bénéficieraient vraiment de l'utilisation du cache d'écriture, mais l'application est sensible au prix et je préfère ne pas doubler le coût de mon sous-système de disque pour certains contrôleurs RAID de mise en cache car je n'ai pas assez d'informations pour savoir si je peux faire confiance au cache de chaque lecteur.

eas
la source
linux permet au cache d'écriture d'être désactivé lecteur par lecteur via hdparam. Pour les disques SATA, je crois que cela doit être scripté pour être réappliqué à chaque redémarrage. Je peux suivre cette voie si je peux encore atteindre nos exigences de performance sans utiliser de contrôleur de raid alimenté par batterie. Je préfère utiliser le logiciel RAID lorsque cela est possible car c'est plus simple et moins cher. Quoi qu'il en soit, je vais certainement avoir un onduleur.
eas

Réponses:

15

De manière générale, en réponse directe à votre question, je ne connais pas de grandes marques de disques SATA pour lesquelles le disque lui-même a eu des bogues relatifs au bon fonctionnement avec la mise en cache d'écriture activée. Autrement dit, du point de vue du lecteur uniquement, le lecteur fait ce qu'il est censé faire du point de vue de la mise en cache. Je voudrais également noter que même lorsque la mise en cache d'écriture est activée, le délai entre l'écriture sur disque du câble SATA et le support rotatif physiquement mis à jour est toujours très court (~ 50 à 100 ms en général). Ce n'est pas comme si les données du cache sales resteraient là pendant des secondes à la fois ..... le lecteur essaie continuellement d'obtenir des données sales du cachesur le support physique dès que possible. Ce n'est pas seulement une question de sécurité des données, mais une question d'être prêt à accepter les futures écritures sans délai (c.-à-d. Écrire des publications).

Le problème qui se pose lorsque la mise en cache est activée est que l'ordre d'écriture sur le lecteur via le câble SATA et l'ordre d'écriture sur le support rotatif ne sont pas les mêmes. Cela ne peut jamais causer de problème À MOINS QUE vous n'ayez une panne de courant ou une panne du système avant que tout le contenu du cache ne parvienne sur le disque. Pourquoi? ->

Le problème qui peut survenir ici est relatif à la robustesse des transactions du système de fichiers et / ou du contenu du fichier de base de données pour ces écritures perdues hors service. En effet, ces écritures potentiellement perdues dans le désordre peuvent théoriquement corrompre l'intégrité de la logique de transaction qui aurait autrement été garantie par les écritures de disque se produisant dans un ordre très spécifique sur le support.

Maintenant, bien sûr, les concepteurs du système de fichiers, des bases de données, des contrôleurs RAID, etc. sont conscients (ou devraient certainement être conscients) de ce phénomène par rapport à la mise en cache d'écriture. La mise en cache en écriture est extrêmement souhaitable du point de vue des performances dans la plupart des scénarios d'E / S de type à accès aléatoire. En fait, disposer de la mise en cache d'écriture est un élément clé pour pouvoir tirer un avantage réel de la mise en file d'attente de commandes native plus avancée ( NCQ)) qui est pris en charge sur les nouveaux SATA et les dernières générations d'implémentations PATA. Ainsi, pour garantir l'ordre des supports physiques à certains moments critiques, le système de fichiers et / ou l'application, etc. peut spécifiquement demander un vidage des caches d'écriture sur les supports. À la fin de cette demande de synchronisation - tout ce qui attend des tampons de fichiers (potentiellement), de la mise en cache du disque du système d'exploitation, de la mise en cache du disque physique, etc. Autrement dit, cela se produit correctement si les programmeurs effectuent le (s) bon (s) appel (s) en haut ET chaque élément de cette chaîne de couches logicielles et matérielles a fait son travail correctement. c'est-à-dire: il n'y a aucun bogue à cet égard dans le lecteur, les contrôleurs RAID, les pilotes de disque, les caches du système d'exploitation, le système de fichiers, le moteur de base de données, etc. C'est beaucoup de logiciels qui doivent tous fonctionner parfaitement. De plus, la vérification de l'exactitude à cet égard est très difficile car dans presque toutes les situations, l'ordre d'écriture n'a pas d'importance du tout .... et les scénarios de panne de courant et de crash sont des tests difficiles à construire. Donc, au final, "désactiver la mise en cache d'écriture" sur une ou plusieurs des différentes couches et / ou significations de ce terme ... a la réputation de "corriger" certains types de problèmes. En effet, la désactivation des comportements de mise en cache d'écriture du contrôleur RAID ou des caches de disque du système d'exploitation, ou du lecteur, etc. évite un ou plusieurs bogues dans le système ..... et la source d'un tel savoir. et les scénarios de panne de courant et de crash sont des tests difficiles à construire. Donc, au final, "désactiver la mise en cache d'écriture" sur une ou plusieurs des différentes couches et / ou significations de ce terme ... a la réputation de "corriger" certains types de problèmes. En effet, la désactivation des comportements de mise en cache d'écriture du contrôleur RAID ou des caches de disque du système d'exploitation, ou du lecteur, etc. évite un ou plusieurs bogues dans le système ..... et la source d'un tel savoir. et les scénarios de panne de courant et de crash sont des tests difficiles à construire. Donc, au final, "désactiver la mise en cache d'écriture" sur une ou plusieurs des différentes couches et / ou significations de ce terme ... a la réputation de "corriger" certains types de problèmes. En effet, la désactivation des comportements de mise en cache d'écriture du contrôleur RAID ou des caches de disque du système d'exploitation, ou du lecteur, etc. évite un ou plusieurs bogues dans le système ..... et la source d'un tel savoir.

Quoi qu'il en soit, revenons au cœur de la question: sous SATA, la gestion spécifique de toutes les commandes de lecture / écriture sur disque et les commandes de vidage du cache sont bien définies par les spécifications SATA . De plus, les fabricants de disques doivent disposer d'une documentation détaillée pour chaque modèle de disque ou famille de disques décrivant leur mise en œuvre et leur conformité à ces règles, comme cet exemple pour les disques Seagate Barracuda . En particulier, voir les détails des CARACTÉRISTIQUES DU SATA SETLa commande qui contrôle le mode de fonctionnement du lecteur et en particulier l'option 82h peut être utilisée pour désactiver la mise en cache du disque au niveau du lecteur car la valeur par défaut est certainement la mise en cache d'écriture activée sur tous les lecteurs que je connais. Si vous vouliez vraiment désactiver le cache, cette commande doit être exécutée au début de chaque réinitialisation ou mise sous tension du lecteur et est généralement sous le contrôle des pilotes de disque de votre système d'exploitation. Vous pourriez être en mesure d'encourager votre pilote de système d'exploitation à définir ce mode via une chose de type IOCTL et / ou paramètre de registre, mais cela varie considérablement.

Grand Jeff
la source
5
Une note éditoriale à ma réponse: les contrôleurs RAID matériels sont réputés bogués par rapport à un grand nombre de problèmes, y compris des problèmes liés à leur implémentation interne de la mise en cache d'écriture. Je ne sais pas pourquoi, mais les contrôleurs RAID anecdotiques semblent être parmi les logiciels les plus bogués jamais écrits en termes de quelque chose qui a une telle utilisation répandue. Il est certainement avantageux d'utiliser du matériel RAID très courant, bien établi et largement déployé de fournisseurs très réputés ..... et même alors, les correctifs pour des problèmes non triviaux semblent trop fréquents!
Tall Jeff
Merci Jeff. J'ai fait beaucoup de lecture là-dessus, et je suis presque aussi confus que jamais. Je pense que le problème avec lequel je me bats maintenant concerne les "barrières d'écriture" qui permettent aux applications et aux systèmes de fichiers d'instruire la couche de blocs pour garantir un ordre d'écriture correct en utilisant les différents mécanismes disponibles. Malheureusement, la mise en place de barrières pose toutes sortes de problèmes. LVM, d'une part, ne les prend apparemment pas en charge, même si les périphériques sous-jacents le font. De plus, il me semble que les administrateurs système devraient avoir la possibilité de demander à fsync de forcer le vidage du cache du lecteur
eas
@eas - Le terme "barrières d'écriture" auquel vous faites référence, je suppose, est le même mécanisme de base que j'ai appelé "synchronisation" ou "vidage" des caches dans ma réponse ci-dessus. Selon vous, cela peut être initié à différentes couches de la "pile" d'accès aux fichiers. Pour construire une véritable barrière d'écriture, elle doit prendre effet à travers toutes les couches qui ont des données d'écriture en attente (c'est-à-dire: des caches sales ou des tampons de réécriture) jusqu'aux médias physiques pour fonctionner réellement comme prévu. Tout maillon déconnecté de cette chaîne est ce qui introduit des problèmes potentiels lorsque les écritures sont réorganisées.
Tall Jeff
Les disques peuvent retarder les écritures sur le média pendant plusieurs secondes, bien sûr s'il y a beaucoup d'autres écritures qui débordent le cache du disque, cela forcera une écriture sur le média. NCQ n'a pas strictement besoin du cache d'écriture, il peut encore avoir de nombreuses commandes d'écriture et de lecture en attente et les émettre dans l'ordre que le disque pense obtenir les meilleures performances, également avec NCQ il n'y a pas de sens à l'ordre des écritures qui fait les systèmes de fichiers et les bases de données doivent utiliser des barrières d'E / S.
Baruch Even
3

D'après mon expérience, un contrôleur de disque de mise en cache sur batterie désactivera le cache sur le disque. Je ne suis pas au courant d'un moyen de désactiver le cache sur disque autrement. Même si vous pouviez désactiver le cache sur disque, les performances en souffriraient considérablement.

Pour une optoin à faible coût, vous pouvez utiliser un onduleur peu coûteux qui peut signaler à votre système un arrêt ordonné.

kevintechie
la source
Mon commentaire ci-dessus aurait dû être ajouté ici. J'apprends toujours ce site.
eas
Certains contrôleurs RAID désactivent le cache sur disque tout le temps, d'autres pas et certains ont un paramètre. Ce comportement dépend fondamentalement de la mise en œuvre de la stratégie de mise en cache du contrôleur RAID. Dans certaines implémentations, ils veulent vraiment contrôler l'ordre d'écriture sur le disque .... et dans d'autres, cela importe moins. Je fais allusion à certains des problèmes ici dans ma réponse.
Tall Jeff
Dans mon ensemble de tests certes restreint (contrôleurs RAID LSI 9261, lecteurs SATA, NL SAS et SAS), j'ai constaté que l'activation du cache d'écriture de lecteur lorsque le lecteur était connecté à un contrôleur RAID avec un cache avec batterie / capacité, ne faisait aucune différence pour performances au-delà du simple fait d'avoir le cache du contrôleur RAID. Je ne dirais pas encore que c'est une règle stricte et rapide, mais il est clair pour moi que le contrôleur RAID désactivant le cache de lecteur n'est pas nécessairement un problème.
Daniel Lawson
2

J'utilise un système RAID avec un supercondensateur plutôt qu'une batterie pour maintenir le cache. Les piles s'usent, doivent être surveillées, doivent être remplacées et représentent un point de défaillance potentiel à ces égards. Un condensateur se charge au démarrage, vide le cache lorsque l'alimentation de l'onduleur tombe en panne, dure pratiquement indéfiniment, ne nécessite pas de surveillance, etc. et un logiciel qui arrête le système proprement en cas de panne - je lui donne généralement 5 à 15 minutes (en fonction de la charge de l'onduleur et donc de la batterie disponible) avant l'arrêt si l'alimentation est rétablie.

Pendant un orage, vous pouvez (ou pouvez avoir - les systèmes d'alimentation s'améliorent) voir les lumières scintiller, parfois juste avant de s'éteindre. Il s'agit d'un appareil appelé réenclencheur. C'est un disjoncteur qui, lorsqu'il est déclenché, essaie de fermer l'interrupteur ouvert au cas où la surcharge était transitoire, ce qui est le plus souvent le cas. S'il ne reste pas fermé après, disons trois essais, il reste ouvert. Le pauvre type doit sortir sous la pluie et s'en occuper. Ne vous sentez pas trop désolé pour lui, tout en ne faisant que deux fois ce que vous et moi faisons et deux fois que si c'est des heures supplémentaires, c'est un travail dangereux.

Richard Rankin
la source
2

L'une des idées fausses si les caches de réécriture de disque sont qu'ils ne perdent des données qu'en cas de perte d'alimentation. Ce n'est pas toujours le cas, en particulier sur les appareils SATA. Si un périphérique sATA contient une erreur (comme un bogue FW de cas de coin ou un bogue de contrôleur) et qu'il se réinitialise ou est réinitialisé en externe, il n'y a aucune garantie que les données dans le cache de réécriture sont toujours disponibles après le blocage.

Cela peut conduire à des scénarios où un périphérique a une erreur transitoire, est réinitialisé, une perte de données se produit dans la perte de tout cache sale, et cela est silencieux au-dessus du niveau de bloc des pilotes.

Pire, la désactivation du cache du lecteur via les outils du système d'exploitation sera également perdue lors de la réinitialisation de l'appareil.Par conséquent, même si un appareil a son cache désactivé au début de la journée, si l'appareil est réinitialisé, il réactivera la mise en cache en écriture différée. Lors d'une autre réinitialisation, l'appareil perdra alors des données.

Les lecteurs SCSI / SAS et certains lecteurs sATA ont la possibilité d'enregistrer l'état du profil d'écriture différée pour garantir que les réinitialisations croisées de la propriété ne sont pas perdues - mais en pratique, cela est rarement utilisé.

Les contrôleurs RAID qui intègrent la couche de bloc dans les couches supérieures peuvent remarquer des réinitialisations de disque et désactiver à nouveau le cache d'écriture différée - mais les contrôleurs sATA et SAS standard ne le feront pas.

Cette limitation s'applique également aux autres paramètres SET FEATURE et similaires qui sont configurés pour les performances et la fiabilité.

Jon Brauer
la source
1

Comme vous le dites, un bon contrôleur RAID alimenté par batterie coûtera cher, mais vous pouvez trouver des contrôleurs Dell Perc5 / i sur eBay pour 100 £ (150 $) et surtout avec RAID5, la vitesse d'un contrôleur comme le Perc5 / i vous étonnera. J'ai plusieurs serveurs avec Perc5 / is et six baies de disques RAID5, et ils sont parmi les disques les plus rapides que j'ai jamais vus. Surtout pour les applications de base de données, les disques rapides améliorent vraiment les performances.

Je mordrais la balle et j'achèterais un contrôleur RAID.

JR

John Rennie
la source
1

Pour autant que je sache, le trucage fsync () est une propriété des contrôleurs RAID alimentés par batterie, pas des disques. Le contrôleur RAID contient une batterie qui peut alimenter son cache d'écriture jusqu'à ce que l'alimentation soit restaurée sur le lecteur et que l'écriture puisse être validée en toute sécurité sur le disque. Cela permet au contrôleur de revenir immédiatement au système d'exploitation, car il garantit un certain niveau d'écriture sur le disque.

Il convient de noter que si le cache d'écriture différée des lecteurs se remplit, les écritures se bloqueront jusqu'à ce que le cache soit réécrit sur le lecteur. Cela signifie que le cache n'est généralement pas aussi efficace lors d'écritures prolongées.

De combien d'IOPS votre application a-t-elle besoin? Êtes-vous sûr que vous êtes limité par le cache d'écriture des lecteurs, ou qu'un petit (par rapport à la mémoire de votre serveur) sur le lecteur sera avantageux?

Dave Cheney
la source
Le test que je fais maintenant est de déterminer l'enveloppe de performance de notre application afin que nous puissions trouver la meilleure façon de monter et descendre. Le cache de lecteur peut être relativement petit, mais avec la mise en cache d'écriture, il donne au lecteur la possibilité de réorganiser les écritures (le cas échéant), ce qui semble pouvoir doubler le débit d'écriture soutenu.
eas