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

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.

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.

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é.

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.

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é.

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

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?