このページは、以下の英語ページの抄訳です。最新の情報については、英語ページを参照してください。

 

 

 

この記事のオリジナルは、Glenn Paulley が sybase.com に 2009 年 10 月に掲載したものです。その中で、Glenn は 一般的なハードドライブの信頼性について語っています。2014年初に発表されたars technicaの記事によると、このブログが書かれた頃と比較して破損率に大きな変化はありません。もちろん、重要なデータであれば、ディスクの障害からデータを守るために、定期的なバックアップをとること、またリカバリーシナリオをテストすることが非常に重要です。

 

 

絶大なスケールのコンピューティング ランドスケーブが、コンピュータサイエンスの領域に貢献したものの一つとして、これらのシステムを統計的に研究することができるようになったということがあります。特に様々なハードウェアやソフトウェアの信頼性を証明または反証することが可能になりました。

 

ディスクドライブに関して言うと、ディスクドライブの信頼性に関するいくつかの大規模な研究 [2,3,4,7] がここ数年の間に発表されています。

特に、Google [4] が行った研究では、ドライブの使用が 3 年を経過すると、障害率が急速に増加 – 6 %から 10%間 – することを示しています。この 3 年という期間は、多くのディスクドライブメーカーが、3 年の保証期間を設けているのと同じ期間であり、たいへん興味深い点です。

また、彼らの研究では、ドライバの最新モデルでは、熱とドライブ障害の間の相関は低いことが示されています。これは、データセンター内でエアコンの使用を控える方向にある中  James Hamilton 氏が最近執筆したと同様です。

最近、FAST 2009 において Amazon の Alyssa Henry 氏 [6] がその基調講演で語った内容によると、Amazon Simple Storage (EC3) データサービスでは、ボード全体で年間 3 – 5 % のハードディスク障害がみられるそうです。しかしながら、Google の調査結果を考えると、Amazon の障害経験は、全てのディスクドライブメーカーに統一的にあてはまるものではないでしょう。

Iliadis氏と Hu氏 [3] は、低コストの磁気メディアへのトレンドが、結果として高い障害率につながっていると考えています。[7] Remzi Arpaci-Dusseauand 氏とウィスコンシン大学マディソン校の彼のチームでもこのようなまとめに至っています。とはいえ、少なくとも、ある程度払った分だけは得ることができるでしょう。

 

これらの研究で報告されている実際の障害率は、ディスクドライブメーカーから提供されている信頼性メトリックスとは大きく異なります。さらに、ディスクハードウェア障害は、このストーリーの一部でしかありません。ウィスコンシン大学の Remzi Arpaci-Dusseau 氏と彼の研究チームは、以前の研究において、磁気メディアにおける トランジェントな エラーは、よくあることであるとしています。2008年2月に、サンノゼで開催された the Linux Storage & Filesystem Workshop のまとめを引用すると、

Ric Wheeler (現 RedHat) 氏は、永続的なエラーハンドリングのトピックについて、セクターのハンドリングのよくないものも「全体障害」にわたってめざましく改善されたというコメントとともに紹介しました。そしてサイレントデータ破損に進み、ファイルシステムに構築されつつあるデータチェックサム(とりわけ BTRFS と XFS) と T 10 DIF の進むサポートによってここでの状況は改善していることにふれました。「強制されたアンマウント」のトピックは、James Bottomley氏が少なくともブロックの観点では全てがとにかく機能しなければならないと主張し、長いディスカッションを引き起こしました ( USB ストレージ取り出しのサプライズが例として参照されました)。 Ric 氏は、NFS が未だ機能しないと反論し、他の人たちは、たとえブロックI/Oが機能したとしても、そのファイルシステムは inodes をまだリリースしない可能性があると指摘しました。Ted Ts’o 氏は、FAST ’08 で発表される研究に興味を引きつけ、エラーがそのブロックとファイルシステムレイヤーでドロップしたり紛失したりした 1,300 のケースを示すことでこのディベートを締めました。(強調を追加しました)

下の [5] では、いくつかのファイルシステムにわたるトランジェントと「ハード」ファイルシステムエラーの欠如または mis-reporting について研究しています。 この研究の要約の最初のパラグラフは以下のとおりです。

ファイルシステムの信頼性は、エラーをいかにうまく propagate (伝播)するかに一部依存しています。我々は、統計的な分析テクニックである EDP を開発しました。これを使うとファイルシステムとストレージデバイスドライバがどのようにエラーコードを propagate するのか分析することができます。Linux 2.6 で全てのファイルシステムと 3 つの主なストレージデバイスを EDP 分析したところ、エラーが不正確に propagate されることが頻繁に発生していることを発見しました。1153 コール (13%) で、ハンドリングされることなくエラーコードがドロップしました。

書き込みキャッシュまたは障害発生中の書き込みは、さらなる問題を発生させる可能性があります。特に Linux システムにおける EXT3 の使用は、EXT3 の ジャーナルに書き込む場合のチェックサムのサポートの欠如 – これは EXT4 ではサポートされています – に起因する壊滅的なハードウェア障害によりファイルシステムを壊してしまう可能性があります。ウィスコンシンの Arpaci-Dusseau 氏と彼の研究チームは、最近このエラー分析を次のレベルに引き上げました [1]。彼らは、意図的かつシステマティックに、以前の研究から知られるファイルシステムで発生するある種のハードやトランジェント障害からリカバリするサーバーの能力を判断するために MySQL データベースにエラーを実装しました。この結果は、先に述べた広範囲のディスク障害の研究とともに、全てのデータベース管理者が懸念する必要性があることを示していると言えるでしょう。私はデータベース管理者の皆様に以下の文献を読み、これらのバックアップを手元にキープすることをお奨めします。

 

 

 

[1] Sriram Subramanian, Yupu Zhang, Rajiv Vaidyanathan, Haryadi S. Gunawi, Andrea C. Arpaci-Dusseau, Remzi H. Arpaci-Dusseau, and Jeffrey F. Naughton (April 2010). Impact of Disk Corruption on Open-Source DBMS. In Proceedings, 2010 IEEE International Conference on Data Engineering, Long Beach, California. To appear.

 

[2] Bianca Schroeder and Garth A. Gibson (February 2007). Disk failures in the real world: What does an MTTF of 1,000,000 hours mean to you?In Proceedings, 5th USENIX Conference on File and Storage Technologies, San Jose, California, pp. 1-16.

 

[3] Ilias Iliadis and Xiao-Yu Hu (June 2008). Reliability Assurance of RAID Storage Systems for a Wide Range of Latent Sector Errors. Proceedings of the International Conference on Networking, Architecture, and Storage, Chongqing, China. IEEE Computer Society, ISBN 978-0-7695-3187-8.

 

[4] Eduardo Pinheiro, Wolf-Dietrich Weber, and Luiz André Barroso (February 2007). Failure Trends in a Large Disk Drive Population. In Proceedings, 5th USENIX Conference on File and Storage Technologies, San Jose, California, pp. 1-16.

 

[5] Haryadi S. Gunawi, Cindy Rubio-González, Andrea C. Arpaci-Dusseau, Remzi H. Arpaci-Dusseau, and Ben Liblit (February 2008). EIO: Error Handling is Occasionally Correct.In Proceedings, 6th USENIX Conference on File and Storage Technologies, San Jose, California, pp. 207-222.

 

[6] Alyssa Henry (February 2009). Cloud Storage FUD (Failure, Uncertainty, and Durability). Keynote address, 7th USENIX Conference on File and Storage Technologies, San Francisco, California.

 

[7] Lakshmi N. Bairavasundaram, Garth R. Goodson, Bianca Schroeder, Andrea C. Arpaci-Dusseau, and Remzi H. Arpaci-Dusseau (February 2008). An Analysis of Data Corruption in the Storage Stack. In Proceedings of the 6th USENIX Symposium on File and Storage Technologies (FAST ’08), San Jose, California, pp. 223-238.

 

 

 

 

===

 

SAP SQL Anywhere に関する詳細情報は、SAP SQL Anywhere Communityページ<英語> を参照してください。

 

上記のコミュニティーに掲載されている技術情報は、順次SQL Anywhere 日本語コミュニティ

に掲載しています。

 

SQL Anywhere に関してはまずはこちらをご参照ください。無期限でご利用いただける無償の Developers Edition もこちらからダウンロードが可能です。

 

SQL Anywhere に関して技術的な質問のある方はコミュニティに登録し、
「+ Actions」から「Ask a Question」機能をご利用ください。

Language には「Japanese」、
Primary Tag には「SQL Anywhere」、
Additional tag には「SAP SQL Anywhere」、
User Tagに「sql anywhere japanese question」

を選択してください。

不具合につきましては、サポート契約者様専用の問い合わせ方法にてお問い合わせください。

 

======================
ご購入に関するお問い合わせ

こちらよりお問い合わせください。

To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply