Existe-t-il un moyen de protéger le SSD contre la corruption due à une panne de courant?

15

Nous avons un groupe de terminaux grand public sur lesquels Linux, un serveur Web local et PostgreSQL sont installés. Nous obtenons des rapports sur le terrain des machines avec des problèmes et après enquête, il semble qu'il y ait eu une panne de courant et maintenant il y a quelque chose qui ne va pas avec le disque.

J'avais supposé que le problème proviendrait simplement de la corruption de la base de données ou de la confusion des fichiers avec des modifications récentes, mais il existe d'autres rapports étranges.

  • fichiers avec les mauvaises autorisations
  • les fichiers qui sont devenus des répertoires (par exemple, index.phpest maintenant un répertoire)
  • répertoires devenus des fichiers
  • fichiers avec des données brouillées

Il y a des problèmes avec la base de données corrompue, mais c'est quelque chose à quoi je pouvais m'attendre. Ce qui me surprend le plus, ce sont les problèmes de base du système de fichiers - par exemple, les autorisations ou la modification d'un fichier dans un répertoire. Les problèmes se produisent également dans des fichiers qui n'ont pas changé récemment (par exemple, le code du logiciel et la configuration).

Est-ce "normal" pour la corruption de SSD? À l'origine, nous pensions que cela se produisait sur certains SSD bon marché, mais cela se produit sur une marque de marque (de qualité grand public.)

FWIW, nous ne faisons pas d'autofsck sur un démarrage impur (je ne sais pas pourquoi, je suis nouveau). Nous avons des onduleurs installés dans certains endroits, mais parfois cela ne se fait pas correctement, etc. Le système de fichiers est ext4.

La question: pouvons-nous faire quelque chose pour atténuer le problème au niveau du système?

J'ai trouvé des articles faisant référence à la désactivation du cache matériel ou au montage du lecteur en mode synchronisation, mais je ne sais pas si cela pourrait aider dans ce cas (corruption de métadonnées et modifications non récentes). J'ai également lu une référence sur le montage du système de fichiers en mode lecture seule. Nous ne pouvons pas faire cela parce que nous devons écrire, mais nous pourrions faire une partition en lecture seule pour le code et la configuration si cela pouvait aider.

Voici un exemple de lecteur sudo hdparm -i /dev/sda1:

Model=KINGSTON RBU-SMS151S364GG, FwRev=S9FM02.5, SerialNo=<deleted>
Config={ Fixed }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=0
BuffType=unknown, BuffSize=unknown, MaxMultSect=16, MultSect=16
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=125045424
IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes:  pio0 pio3 pio4
DMA modes:  mdma0 mdma1 mdma2
UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5 *udma6
AdvancedPM=yes: disabled (255) WriteCache=enabled
Drive conforms to: Unspecified:  ATA/ATAPI-3,4,5,6,7
Yehosef
la source
5
Vous pouvez acheter de meilleurs SSD. Les disques SSD d'entreprise typiques ont des condensateurs intégrés pour fournir suffisamment d'énergie à l'appareil pour terminer l'écriture des données en vol en cas de panne de courant. L'argent que vous économisez en n'ayant pas à récupérer à partir d'un système de fichiers totalement brouillé justifiera facilement le coût supplémentaire modeste.
Michael Hampton
1
Eh bien, personne n'a dit que vous deviez tous les remplacer . Mais vous pouvez utiliser les meilleurs SSD pour les remplacements et / ou les nouvelles installations.
Michael Hampton
2
"Ce n'est pas simple de les remplacer tous" - c'est totalement le cas. Commencez par dire au gars qui a fait la décision d'achat qu'il est responsable du coût en raison d'une négligence grave et de l'incompétence.
TomTom
7
WriteCache=enabled. Ceci est un énorme problème. Le cache d'écriture ne doit jamais être activé sur les disques durs dotés d'une base de données. Certains fournisseurs, HP par exemple, empêchent en fait d'activer la mise en cache de l'écriture sur le disque dur pour cette raison.
Greg Askew
3
@Yehosef notez que la désactivation de la mise en cache d'écriture dans le système d'exploitation ne résoudra pas le fait que votre lecteur corrompt les données en cas de panne de courant. Dans un souci de vitesse et de durabilité plus élevées, les SSD de qualité grand public peuvent ne pas écrire de données dans la mémoire non volatile lorsque vous écrivez dans un fichier, et malheureusement, il n'y a pas de mécanisme matériel pour que le lecteur transfère les données du cache volatil vers un stockage non volatile sur panne de courant, seuls les SSD d'entreprise peuvent le faire. Croyez-le ou non, j'étais dans une situation similaire où quelqu'un a acheté beaucoup de SSD grand public, notre fournisseur qui a cité ce matériel n'avait aucune idée que cela se produirait.
2018

Réponses:

14

En cas de coupure soudaine de puissance, les SSD MLC / TLC / QLC ont deux modes de défaillance:

  • ils perdent les écritures en vol et en DRAM uniquement;
  • ils peuvent corrompre toutes les données au repos stockées dans la page inférieure de la cellule NAND en cours de programmation.

La première condition de panne est évidente: sans protection de l'alimentation, toutes les données qui ne sont pas sur un stockage stable (c'est-à-dire: NAND lui-même) mais uniquement sur un cache volatile (DRAM) seront perdues. La même chose se produit avec les disques mécaniques classiques (et cela seul peut faire des ravages sur le système de fichiers qui n'émet pas correctement fsyncs).

La deuxième condition d'échec est une affaire MLC + SSD: lors de la reprogrammation du bit de page haute pour stocker de nouvelles données, une perte de puissance inattendue peut détruire / altérer le bit inférieur (c'est-à-dire: les données validées précédentes ) également.

La seule vraie solution, et la plus évidente, consiste à intégrer un cache DRAM protégé contre les pertes de puissance (généralement à l'aide de batterie / supercaps), comme cela est fait depuis toujours par les contrôleurs RAID haut de gamme; cependant, cela augmente le coût / prix du lecteur. Les disques grand public n'ont généralement pas de caches protégés contre les pertes de puissance; ils utilisent plutôt un éventail de solutions plus économiques comme:

  • cache d'écriture partiellement protégé (par exemple: Crucial M500 / M550 / M600 +);
  • NAND change de journal (c'est-à-dire: lecteurs Samsung, voir attribut SMART PoR);
  • des régions NAND SLC / pseudo-SLC spéciales pour absorber de nouvelles écritures sans données antérieures à risque (par exemple: Sandisk, Samsung, etc.).

Revenons à votre question: vos disques Kingstone sont très bon marché, utilisant un contrôleur non spécifié et essentiellement aucune spécification publique. Cela ne m'étonne pas qu'une coupure de courant soudaine ait corrompu les données précédentes. Malheureusement, même la désactivation du cache DRAM du disque (avec l'énorme perte de performances qu'il commande) ne résoudra pas votre problème, car les données précédentes (c'est-à-dire les données au repos) peuvent et seront corrompues par des pertes de puissance inattendues. S'ils sont basés sur l'ancien contrôleur Sandforce, même une brique de lecteur totale peut être attendue dans les «bonnes» circonstances.

Je vous suggère fortement de revoir votre onduleur et, à moyen terme, de remplacer ces disques vieillissants.

Une dernière remarque à propos de PostgreSQL et des autres bases de données Linux: elles ne désactiveront pas le cache du disque et ne devraient pas être supposées le faire. Au contraire, ils émettent des fsyncs / FUA périodiques / requis pour valider les données clés dans un stockage stable. C'est la façon dont les choses devraient être faites à moins qu'il existe une raison très convaincante (c'est-à-dire: un lecteur qui ment sur ATA FLUSHES / FUAs).

EDIT: si possible, envisagez de migrer vers un système de fichiers à somme de contrôle en tant que ZFS ou BTRFS. À tout le moins, considérons XFS, qui a une somme de contrôle de journal et, récemment, même une somme de contrôle de métadonnées. Si vous êtes obligé d'utiliser EXT4, pensez à activer l'auto-fsck au démarrage (fsck.ext4 est très bon pour réparer la corruption).

shodanshok
la source
Excellente réponse. Veuillez consulter ma question connexe serverfault.com/questions/924054/… - si vous souhaitez copier / adapter cette réponse là-bas, je serais heureux de voter / de la sélectionner. Il semble que la désactivation du cache d'écriture ne soit utile que dans le premier cas. Avez-vous plus de détails sur le deuxième mode d'échec? Est-ce lié au rééquilibrage / ramasse-miettes ou simplement à la proximité?
Yehosef
1
@Yehosef Regardez ici, dans la section "perte de puissance": anandtech.com/show/8528/…
shodanshok
1
Le problème avec toute solution logicielle est que de nombreux SSD incombent au système d'exploitation pour savoir si les données sont stockées en toute sécurité ou non, y compris en réponse aux commandes fsync / FUA. Pour les disques d'entreprise qui disposent d'un stockage d'énergie suffisant pour terminer le vidage de son cache lorsque l'alimentation est coupée, ce n'est pas un problème.
BeowulfNode42
@ BeowulfNode42 Les barrières ATA et les FUA doivent être respectées . Alors que dans les jours IDE / PATA, certains disques falsifiés, de nos jours, un tel disque "menteur" n'est pas compatible SATA / SAS, et devrait immédiatement être jeté.
shodanshok
et pourtant ces disques non conformes sont vendus de toute façon, en particulier dans le segment de marché grand public.
BeowulfNode42
11

Ouais. Ne vous procurez pas de SSD super bon marché - tout ce qui se trouve en dehors du marché des consommateurs bas de gamme a des condensateurs et une protection complète contre les coupures de courant. Amd ne coûte vraiment pas beaucoup plus cher.

TomTom
la source
Ils sont Kingston - donc je ne sais pas si ceux-ci sont considérés comme bon marché ou si c'est un lot défectueux. Le plus gros problème est que les unités (~ 6k) sont déjà sur le terrain et la plupart ne sont pas en panne (peut-être simplement parce qu'elles n'ont pas de perte de puissance). Les remplacer est donc un dernier recours coûteux que nous n'avons pas encore atteint.
Yehosef
ajouté des informations sur le lecteur à la question.
Yehosef
5
Ils sont super bon marché. Ce sont des lecteurs utilisateurs finaux orientés prix. Recherchez les disques pour petites entreprises. LISEZ LES SPÉCIFICATIONS. En règle générale, la protection contre les pannes de courant fait partie des spécifications.
TomTom
1
Pour ajouter à @TomTom - parfois ce n'est pas réellement appelé protection contre les coupures de courant - et parfois, la protection contre les coupures de courant n'est pas vraiment une véritable protection contre les coupures de courant! Vous devez faire quelques lectures pour chaque fabricant et savoir comment ils l'appellent pour leur marque particulière de SSD d'entreprise. (Regardez, pour chaque mfr, pour les papiers blancs qu'ils ont écrit sur la façon vraiment supérieure leurs propres disques SSD d'entreprise sont.) Et, je l' ai constaté que, au moins pour les achats individuels, il ne coûtera un peu plus. Mais je ne fais pas d'achats en vrac et cela pourrait être différent pour des quantités de 100 ou plus, je suppose.
davidbak
3
D'après ce que j'ai lu jusqu'à présent, ces fabricants ont les noms de cette fonctionnalité comme: Kingston = "Pfail" comme sur la série DC400; Samsung = "Power Loss Protection"; Intel = "Enhanced Power Loss Data Protection"; Sandisk = "Protection contre la perte de données avec protection contre les pannes de courant". Je ne sais pas comment les autres fabricants l'appellent, mais une lecture approfondie des fiches techniques est nécessaire. Notez que cela peut également être réalisé avec le firmware si le fabricant le fournit. Si vous en avez vraiment> 6000, je contacterais Kingston et expliquerais la situation et proposerais de payer le firmware par lecteur.
BeowulfNode42
7

La première chose à faire est de définir le temps de récupération et les objectifs des points de récupération. De combien de temps disposez-vous pour récupérer l'un de ces terminaux, et quel moment de données est acceptable? Peut-être que dans quelques heures, vous devez être capable de récupérer la sauvegarde de la semaine dernière.

Toutes sortes de choses étranges peuvent arriver aux fichiers si les écritures en vol sont perdues. La priorité du système de fichiers est de maintenir leur propre cohérence des métadonnées, ils peuvent ne pas fournir les mêmes garanties pour vos données. En d'autres termes,fsck n'est pas garanti de récupérer vos données. Son travail consiste à vous procurer un système de fichiers à monter.

Alors, le pouvoir. Installez, configurez et testez que l'onduleur arrêtera le système correctement. Cela permet aux caches du système de fichiers et aux lecteurs eux-mêmes d'écrire.

Et, la durabilité des écritures sur les disques. Lire le chapitre sur la fiabilité de PostgreSQL . Utilisez le diskchecker.plscript qui y est lié pour effectuer un crash test et déterminer si les SSD mentent si les écritures sont arrivées sur un stockage non volatile. En cas de perte, envisagez de les remplacer par des disques SSD connus pour être protégés contre les coupures de courant.

Modifier: vous avez ajouté des détails sur l'écriture du cache activé Vous pouvez essayer de désactiver cela: hdparm -W0 /dev/sdaou la commande appropriée pour une matrice matérielle. Référence: Guide d'administration du stockage RHEL .

Les barrières d'écriture du système de fichiers appliquent un ordre de validation de journal. Ce n'est pas une garantie que les données seront intactes, mais c'est plus sûr pour le système de fichiers avec un cache volatile. Bien qu'il s'agisse de la valeur par défaut, l'ajout de l'option de montage "barrière" documente clairement la valeur que vous accordez à la cohérence par rapport aux performances.

Enfin, la dernière ligne de défense. Faites un test de restauration pour vous assurer que vous pouvez obtenir votre application et votre base de données au moment souhaité. Ceci est utile pour toutes sortes de pertes de données, pas seulement pour les pannes de courant.

John Mahowald
la source
Cette mise en cache d'écriture sur disque est la réponse probable. Pour une raison inconnue, il semble que Postgres ne désactive pas la mise en cache de l'écriture sur disque, ce qui est un terrible paramètre par défaut.
Greg Askew
1
Pour clarifier - nous avons des sauvegardes quotidiennes et nous synchronisons les données sur le cloud, donc le problème est moins lié à la perte de données Postgres (c'est un problème, mais je pense qu'il existe des options de configuration PG qui peuvent aider.). Le problème le plus préoccupant est que la machine devient inutilisable liée à la bizarrerie des métadonnées. FWIW, généralement la machine démarre et nous pouvons nous y connecter, mais l'application échoue car ses fichiers ont été brouillés.
Yehosef
1
"il semble que Postgres ne désactive pas la mise en cache de l'écriture sur disque, ce qui est un terrible paramètre par défaut." @GregAskew Veuillez expliquer comment désactiver le cache DRAM sur le SSD coimsumer. Il ne peut pas être désactivé.
TomTom
4
En raison du fonctionnement du SSD. Sans cache d'écriture, vous brûleriez le SSD beaucoup plus rapidement. Les cellules SSD sont grandes et doivent toujours être entièrement écrites - la capacité de combiner plusieurs petites écritures est donc cruciale pour la durée de vie des SSD. C'est pourquoi vous NE POUVEZ PAS le désactiver sur les disques grand public (les disques mentent ou ne le permettent pas) ET ne pouvez pas le faire sur les disques d'entreprise (les disques peuvent essentiellement mentir car ils ne sont pas volatils - ils ont suffisamment de réserves d'énergie pour écrire le dram out à clignoter.
TomTom
3
@Yehosef Non, même pas fiable Postgres a le pouvoir de la magie de récupérer s'il a envoyé des données vers le lecteur, le lecteur dit "Bien, a obtenu vos données", puis le lecteur n'a jamais pu écrire ces données à partir de son volatile temporaire interne cache au stockage non volatile réel. Il est crucial d'utiliser uniquement un stockage de qualité entreprise où le lecteur ou l'unité RAID a son cache interne soutenu par une batterie ou un condensateur. Postgres possède des fonctionnalités (fichier WAL, etc.) pour vous protéger contre la perte de données non encore envoyées au lecteur, mais Postgres ne peut pas récupérer les données perdues à l' intérieur du lecteur.
Basil Bourque