HPEのサーバーやストレージで使われているSSDで不具合、SHRT_MAX+1時間の稼働でデータ喪失 76
ストーリー by hylom
どうしてこうなった 部門より
どうしてこうなった 部門より
エンタープライズ向け製品を手がけるHewlett Packard Enterprise（HPE）のサーバーやストレージで使われている特定のSSDで、稼働時間が32768時間（約3年270日8時間）を超えるとデータが喪失する不具合が確認されているとのこと（PC Watch）。
ファームウェアが原因とのことで、「32768」はshort intの最大値である32767を超えた値であることから、SSDの内部でのデータの取り扱いに何らかのミスがあったのではないかと見られている。HPEはこれに対応するためのファームウェアを配布しており、利用者に対してはすぐの適用が呼びかけられている。
はたしてhpeだけなのか？ (スコア:1)
対象SSD一覧に掲載されている「VK007680JWSSU」でぐぐるとVMware Compatibility Guideの「モデル:HPE 7.68TB SAS RI SFF SC DS SSD [vmware.com]」が出てくるわけなんですが、そこには「ベンダーID: Samsung」「シリーズ: PM1643」という文字列が
はたしてこのバグはhpe向けカスタムモデルのみなのか、それとも自社ブランドのPM1643や、他社…例えばLenovo向けのPM1643 [lenovopress.com]にも適用される話なのか
続報はどうなるかな
Re:はたしてhpeだけなのか？ (スコア:1)
この（HP曰く）SSDの不具合で、SSDのベアドライブ自体にアクセスできなくなるのか、SSDが正常なデータを返さなくなることで、エンクロージャが誤動作するのか。
後者なら他社への波及は最小限になるのではないでしょうか。
後者だと例えばこんな感じでしょうか。詳報出るんでしょうかね。
・SSDがSMARTでおかしな値を返す
・エンクロージャのファームウェアがSSD故障と判断して切り離し
・ホットスペアにリビルド中に別のSSDも次々とエラー
・結果としてマルチデッド
Re: (スコア:0, すばらしい洞察)
こんなんパッと見て「ああSSDのコントローラがクラッシュして沈黙すんのね」って分かるでしょ。
分からん?
Re:はたしてhpeだけなのか？ (スコア:1)
事態の悲惨さを認めたくないからでしょw
RAIDアレイから退避させて取り出してファームアップ
リビルド完了を待ってからアレイに組み込んでまた退避して…
全部にファームあてるのに何日かかるのさw
RAIDの構成によっちゃ下手したら今から始めても来年まで終わらんぞ
Re:はたしてhpeだけなのか？ (スコア:1)
今のこの系統のシステムってRAIDコントローラ経由でファームウェアアップデートさせて計画再起動一回で済む設計になっているはずだけど。
絶対止められないシステム構成なら、片系再起動できるはずでしょうし問題ないような...
Re:はたしてhpeだけなのか？ (スコア:1)
調べてみましたが、ベンダーが HPと書かれているeMLCのものもSamsung製でした (･ω･)
HPD8に不具合と書いてるので、HP向けにカスタムで作ったサムスン電子のファームの問題で、他社だと同じハードでも問題でなかったりするのでは…？（PM1643 量産開始したのが 2018年、HPD9に切り替わったのが 2015年後半ごろっぽいので HPE だけとか）
SSDのRAID化 (スコア:1)
サーバ用途でもSSDが普及してきてますが、SSDの場合にRAID1とか5にする必要性はあまり無いような気がするんですけどどうなんでしょう。
ハードディスクの場合、物理的に壊れるリスクが高いのでRAIDを組むのが一般的ですが、SSDがハードウェア的に壊れる確率ってそれほど高くないのでは。
Re:SSDのRAID化 (スコア:1)
// 速度的なものでRAID化する意味はあるのですが
Re:SSDのRAID化 (スコア:1)
HDDはセクタが壊れると代替セクタに移行します。代替セクタの様子を見ているとだいたい壊れる時期がわかるそうです(駄
SSDは物理的には磁気メディアよりも信頼性がないわけで代替がたくさんあるわけですが、これが書けなくなるまで「壊れた」というレポートをしないのに、書けなくなったとたん壊れてしまうので「突然壊れた」ように見えるわけです。
内部的に「時間」を使ってるのか (スコア:0)
こういったのって、内部では秒をつかって
表示・出力するときに時間とかに換算する場合が多いと思ってたけど、
内部でも時間をつかってたのか
Re:内部的に「時間」を使ってるのか (スコア:1)
これ、HPE限定なのか、DELLやらOEM元の他社製品でもアップデート来るんですかね。
時間を使うのは、電源断して、次回起動時に時間を覚えていないと意味が無いので、データ保存したけど、隣のデータ壊したとか、
チェックサム異常でSSDのファームが起動途中で止まるとか、A/B面あって、不整合検出して止まったとかいったシナリオが有ると思います。
なんというか、m4の悲劇 [it.srad.jp]再び。
m4は電断してリブートして更新したらデータは残ってたので、それより悲惨か。
通電時間カウント回りは陥りやすいのか、Intelも1700時間で死亡やらかしてたり。 [intel.com]
全然関係ないけど、1700時間で死んだIntelのDC向けSSDに修正ファーム新しいのが来てる。 [intel.com]
Intel® Solid State Drive DC P4510 and P4610 and P4511 Series Revision History
November 2019 VDV10170 MR7 firmware release.
やっぱSSDもソフトウェア(ファームウェア)が鬼門ですね。
# HDD時代でも有ったけどさ。
Re:内部的に「時間」を使ってるのか (スコア:1)
電源断して、次回起動時に時間を覚えていないと意味が無いので
時間単位でカウントということは稼働中は「前回と同じ値」となることの方が圧倒的に多そうで、そういう「時間を覚えておかないと困る」というシチュエーションがいまいち思い浮かばない。
他のコメントにあるSMARTがらみで時間単位のカウントが必要というのは十分ありそうだけど、SMARTのためだけに保存している情報なら「データが喪失する」ほどSSD自体の動作に影響を与えるもんなんだろうか？
とかモヤモヤしますね。
うじゃうじゃ
Re:内部的に「時間」を使ってるのか (スコア:1)
データはNAND上に有っても、ファームウェアが起動しないなら、結果的にSSDとしては機能しなくなります。
ファームウェア更新のみ可能なモードとか、外部からコマンドを受け付けるまで起動すれば希望は有りますが。
万が一管理領域自体が壊れて失われてしまうとNAND上に有るデータは断片化された状態(SSDは、NANDへの書き込み回数の平均化のために連続データも飛び飛びにされる)になり復旧は絶望的になります。
他にも今時はデータをSSD内部で暗号化してから記録している奴が有るのですが、この鍵も管理領域破損時に一緒に飛んだとか、NAND上になくて、開封と同時に鍵が飛ぶ対タンパ仕様だと、完全に積みで「データは結果的に喪失」します。
Re: (スコア:0)
気にしてるのはそこじゃなくて「(おそらくSMART用と思われる)稼働時間カウンタの値が不正なことが、ファームの動作に影響を与えるシチュエーションがいまいち思い浮かばない」なんですが。
一時間単位のような粗いカウンタを参照する必要性があるの？ってとこ。
Re:内部的に「時間」を使ってるのか (スコア:1)
あれ？匿名になっちゃった。
間違ってチェックボックスクリックしたのかな？
うじゃうじゃ
Re:内部的に「時間」を使ってるのか (スコア:1)
ほぼ解決済みのような気がしますが、異常データが入ってきたときにどうするかは設計方針によるかと思います。
大前提として、ストレージに関しては、故障で止まるよりも、壊れたデータが読めた時の方が被害は拡大します。
有り得ない負数が入ってきた＝NANDメモリ等が致命的な障害を起こしたと判定して、
それ以降読んだり・書き込んで状況を悪化させない設計というのも「アリ」だと思いますよ。
管理エリアのデータが壊れた＝書き込めば無事かもしれないデータもどんどん失われるですからね。
Re:内部的に「時間」を使ってるのか (スコア:1)
なるほど、書き込み頻度が高いとこを見つけるのは回数だけ見れば十分だろうけど、頻度の低いとこを探すには経過時間を基準にした方がいいだろうし、精度が粗くても支障はない。
だけど元にするカウンタがオーバーフローする可能性は見落としていたと。
本当にそれが理由かはわからないけど、なんかありそうですね。
(すばらしい洞察)
うじゃうじゃ
Re:内部的に「時間」を使ってるのか (スコア:1)
一瞬だけそれは考えたけど、最上位ビットによって書き込みサイズが変化するなんてのはわざわざそうする必要があるとき(UTFのような可変長エンコードとか)にするめんどくさい実装であって、そんなのをうっかり仕込んでしまったと考えるのはかなり無理があるので自分の中では却下した。
うじゃうじゃ
Re: (スコア:0)
SSDってのはそれ自体がRTOSを積んだシングルボードコンピュータなので
不正な設定データを読み込むと落ちるようなタスクがあった場合はブートループに陥っても不思議はない
Re: (スコア:0)
カウンタのオーバーフローを避けようとすると変数のサイズを上げるかカウンタの精度を下げるかの二択。
でカウンタの精度は落としたくないので一時間未満は秒一時間以上を時の二変数体制にしたんでしょう。
ウインドウズの可動時間計測の実装よりはスマートな気がしますけど。
次は32768日稼働すると落ちるようになる？
Re: (スコア:0)
総稼働時間をSMARTに入るように(int)にキャストしたんじゃないの
Re: (スコア:0)
HDD/SSDのSMART(Self-Monitoring, Analysis and Reporting Technology)では、「通電時間」とか時間単位でカウントする機能を持っていたりするので。
言語によって違うけど (スコア:0)
Cだとshort intの最大値はSHORT_MAXで、具体的な値は処理系依存だったような…
Re: (スコア:0)
SSDコントローラに組み込まれてるCPUコアって、だいたいARMだとおもう
これなら最低32bitはあるはず
なのでSHORT_MAXは20億はあるはず
わざわざ明示的にint16を使ったのか、
それともCPUコア以外の部分で16bit実装してたのか
Re: (スコア:0)
SSDコントローラに組み込まれてるCPUコアって、だいたいARMだとおもう
これなら最低32bitはあるはず
なのでSHORT_MAXは20億はあるはず
どういう理屈??
Re: (スコア:0)
INT_MAXと取り違えているのに一票。
Cの規格上だと、SHRT_MAXもINT_MAXも「32767(2^15-1)以上」ってことになっているけど、intが64bitになったってSHRT_MAXが32767以外になっている処理系に出会ったことはないなぁ。
# WORDとかDWORDとかtypedefしているのをメンテすることあるけど、これはほんと止めて欲しい。サイズも符号の有無も判らなくて、いちいちtypedefしているところを探す羽目になる。最悪なのは、同一プロジェクト内で何にtypedefしているかバラバラなこと。
Re:言語によって違うけど (スコア:1)
ひょっとしてこれがあるかな？
SATAのコマンドフレームとしてWORD=32bitで表現しているので設計者は32bitあると思い込んでいたが、実際にWORDをtypedefしていたファイルは8bitマイコン時代から使い回していたシロモノでWORD=16bitだったとか。
Re: (スコア:0)
SHORT_MAXって何ですか？
というのはおいておき、GCCもVCもSHRT_MAXが32767で、INT_MAXが2147483647の実装だと思うのだが。
Re: (スコア:0)
今の時代、処理系依存するような型をクリティカルな場所で使用するなよぉ。
stdint.h の存在を知らなかったとはいはせない。
それともやはり、アセンブラで書いているとか。
Re: (スコア:0)
stdint.hも処理系依存なんだが・・
Re: (スコア:0)
処理系依存と言っても int32_t が使えて実は16bitなんて事はありえないでしょ。
定義されてない場合はあるにしても。
32767時間じゃないんでしょうか？ (スコア:0)
気になる...
# パッチ後は65535時間に延長されるだけだったりして...
Re:32767時間じゃないんでしょうか？ (スコア:1)
意表をついて「32767日」だったり。
ドヤ顔で「耐用時間が24倍になりました！！」
Re: (スコア:0)
> # パッチ後は65535時間に延長されるだけだったりして...
7年超になれば、実質的に問題なくなりそう。
その前にどこか別のところが壊れるから。
Re: (スコア:0)
もともと7年超でデータ消去して強制的に買い替えさせる設計だったけど
signedとunsigned間違えて前倒しになったのか?
Re: (スコア:0)
インテルのSSDを5万時間使ってもまだ壊れてないから65535時間は十分あり得る時間かと
RAID死 (スコア:0)
RAIDにして「1個や2個壊れても大丈夫！」と思ってたら、全部が一斉に壊れるとなると・・・
Re:RAID死 (スコア:1)
RAIDにして「1個や2個壊れても大丈夫！」と思ってたら、全部が一斉に壊れるとなると・・・
RAID 0 ＜ ( ´∀｀)人(´∀｀ )ﾅｶｰﾏ
Re: (スコア:0)
RAID（1とか5）で同じロットのディスクを使ってはならんのだ。
Re: (スコア:0)
稼働時間が問題なわけだから、この問題に関してはロット違ってもあんまり意味ないような…
Re:RAID死 (スコア:2)
それはそうなんだけど、ロットが違えば、ファームウェアバージョンが違う可能性もあって、まったく無意味というわけでも無い。
Re: (スコア:0)
それがやりたかったら装置自体を多重化してくださいね
Re:RAID死 (スコア:1)
「装置」って何のこと?
RAIDコントローラ?
電源?
筐体?
いずれにせよ、多重化は可能ですが、金はかかるわけです。
しかし、ディスクのロットを違えることにかかる金は、それに比べれば非常に小さい。
ならば、費用対効果を考えて、ディスクのロットだけ変える、という判断があってもヘンではありませんよ。
Re: (スコア:0)
ドヤ顔で「プロはディスク玉のメーカーやロットを変える！」とか主張する人がたまにいるけど
ストレージベンダーでもフォルトトレランスシステムベンダーでもそんなことやってないｗ
EMCとかStratusの中開けたら普通に同ロット同メーカーのディスク玉並んでるぞ。
予備交換でズレてることはあるけど。
Re:RAID死 (スコア:1)
効果が限定的だ、と考えて、やらない、という選択肢もまたヘンではありません。
どっちもあり得る、という話をしています。
ところで、「予備交換」はあまり聞かないですね。
「予防交換」って言いません?
Re: (スコア:0)
同時稼働したら同じなので、半年後に予備をさらに買って入れ替えないと。
テスト環境を本番に格上げ、バックアップを追加購入な環境なら猶予があるかもしれない。
Re:RAID死 (スコア:1)
一言にすると「中途半端」なんだけど、違うロットのHDDを混ぜるって
違う仕様の製品を混ぜるも同義だから、工学的直感として恐怖を感じない?
「違うメーカーの電池を混ぜると一本が短絡故障しても電圧が残るんじゃないか?」とか、
「違う容量の電源を並列運転すると負荷追従に役立つんじゃないか?」とか…言わないよね?
それ一機に負荷が集中したり妙な振動起こしたりしてアカンことになりません? って思うよね?
HDDに関してはっきりと言える知識はないけどなんとなーく怖いナァ、って思うと
「その考え方は中途半端。そもそも…」って言い方になるんじゃね?
Re: (スコア:0)
データ復旧業者もお手上げな壊れ方するらしいね。
まぁもともとSSDは復旧が難しいらしいが。
Re: (スコア:0)
Re:早速それっぽい障害が (スコア:1)
「HPEのストレージではないので無関係」と思っているかもしれないが、HPEへのSSD供給元と同じところが製造したSSDが搭載されていると、大当たりかもしれないね。
今のところHPEはSSD供給元を明かしていないので、なんとも言えない。