ECCメモリを購入する必要がありますか？

おそらく最も広く読まれているブロガープログラマであるジェフアトウッドは、 ECCメモリ使用量に対する投稿を公開しました。 私の理解では、彼の主張は次のとおりです。

1. Googleは、1999年にサーバーを構築したときにECCを使用しませんでした。
2. ほとんどのRAMエラーは、システムエラーであり、ランダムなエラーではありません。
3. ハードウェアが改善されたため、RAMエラーはまれです。
4. ECCメモリが非常に重要な場合は、サーバーだけでなくどこでも使用されます。 この種のオプション素材の料金は明らかに疑わしいです。

これらの引数を1つずつ見てみましょう。

1. 1999年にGoogleはECCを使用しませんでした

Googleが一度やったからといって何かをしているなら、試してみてください：

A.サーバーをトランスポートコンテナーに入れます。

今日、これは素晴らしいアイデアであるという記事がまだ書かれていますが、Googleは失敗したと思われる実験を行ったところです。 Googleの実験でさえ常に成功するとは限りません。 実際、「ブレイクスループロジェクト」（「ランショット」）へのよく知られた依存症は、ほとんどの企業よりも失敗した実験が多いことを意味します。 私の意見では、これは彼らにとって大きな競争上の優位性です。 失敗した実験を盲目的にコピーして、この利点をそれ以上にしないでください。

B.自分のデータセンターで火災を引き起こします。

Atwoodの投稿の一部では、これらのサーバーがどれほど素晴らしいかについて説明しています。



これらの初期のGoogleサーバーを見て、火災の危険性に関するプロ意識の欠如を見る人もいます。 私じゃない。 ここでは、安価な標準機器が現代のインターネットをどのように形成するかについての先見の明のある理解を参照してください。



言われたことの最後の部分は真実です。 しかし、最初の部分にはいくつかの真実があります。 Googleが独自のボードの開発を開始したとき、ある世代には「成長」の問題がありました（ 1 ）ゼロ以外の数の火災を引き起こしました。



ちなみに、Jeffの投稿に移動して、引用が参照している写真を見ると、ボード上にジャンパーケーブルがたくさんあることがわかります。 これは問題を引き起こし、次世代の機器で修正されました。 また、かなり厄介なケーブル配線を見ることができます。これは、さらに問題を引き起こし、すぐに解消されました。 他の問題もありましたが、読者のための演習として残しておきます。

C.従業員を傷つけるサーバーを構築する

Googleサーバーの世代の1つの鋭いエッジは、「カミソリの刃と憎しみ」から作られたという評判を獲得しました。

D.データセンターで天気予報を作成する

多くの大規模なテクノロジー企業の従業員と話をした後、ほとんどの企業は、データセンターに雲や霧が形成されるほどの気候制御を受けていたようです。 Microsoftの従業員を誘惑するために、Googleの慎重で危険なシアトルの天気予報と呼ぶことができます。 あるいは、文字通り「クラウドコンピューティング」を作成する計画とすることもできます。 またはそうでないかもしれません。



上記のすべてのGoogleが試してから変更したことに注意してください。 間違いを犯してから排除することは、開発に成功している組織ではよくあることです。 エンジニアリングの実践を偶像化する場合、1999年にやったことではなく、少なくとも現代の実践を続けるべきです。



Googleが1999年にECCなしのサーバーを使用したとき、最終的にはメモリ破損が原因であることが判明した多くの症状を示しました。 事実上ランダムな結果をクエリに返す検索インデックスを含める。 ここでは、実際の障害モードは有益です。 個々の結果のエラーは有効であるため、これらのマシンではECCを無視できるとよく耳にします。 ただし、ランダムエラーを許容できると考えても、それらを無視することは、1つのエラーが1つの結果をわずかにしか歪めないことを徹底的に分析しない限り、完全なデータ破損の危険性があることを意味します。



ファイルシステムに関する研究により、1つのエラーに耐えるシステムを作成しようとする勇敢な試みにもかかわらず、それを行うことは非常に難しいことが繰り返し示されています。 基本的に、単一のエラーが原因で、厳しくテストされたすべてのファイルシステムがクラッシュする可能性があります（ これに興味がある場合は、ウィスコンシン州のAndreaとRemziの調査結果を参照してください ）。 ファイルシステム開発者を攻撃するつもりはありません。 プログラマーの99.9％よりも、こうした分析に精通しています。 この問題は非常に難しく、人々が合理的に議論できないことが繰り返し示されてきましたが、このような分析のための自動化ツールは、ボタンをクリックするだけのプロセスからはほど遠いものです。 Googleは、ウェアハウスデータのコンピューター処理に関する参考資料でエラーの検出と修正について説明しています。ECCメモリは、ハードウェアエラー修正を使用する必要があることが明らかな場合に最も正しいオプションと見なされます（ 2 ）



Googleには優れたインフラストラクチャがあります。 他の主要なIT企業のインフラストラクチャについて聞いたところから、Googleは世界一だと思われます。 しかし、これは、彼らが行うすべてをコピーする必要があるという意味ではありません。 たとえ彼らの良いアイデアだけを考慮しても、ほとんどの企業にとってそれらをコピーすることは意味がありません。 彼らは、Linuxインターセプトスケジューラーに代わるものを作成しました。これは、ランタイムハードウェア情報と静的トレースの両方を使用して、Intelサーバープロセッサーの新しいハードウェアを活用し、コア間でキャッシュを動的に分割できるようにします 。 すべての機器でこれを使用すると、Googleは1週間でStack Exchange会社が全歴史のすべてのマシンに費やしたよりも多くのお金を節約します。 これは、Googleをコピーする必要があるということですか？ いいえ、たとえば、メインインフラストラクチャが高度に最適化されたC ++で記述され、Javaや（神は禁じられている）Rubyではなく、天国からのマナがあなたに落ちていない場合。 そして事実は、生産性の20倍の低下を伴う言語でプログラムを書いている企業の大多数にとって、完全に合理的な解決策であるということです。

2.ほとんどのRAMエラーは系統的なエラーです。

ECCに対する議論は、DRAMエラー研究の次のセクションを再現しています （Jeffが強調）。

私たちの研究にはいくつかの主な結果があります。 最初に、 DRAM障害の約70％が反復的な（たとえば、永続的な）障害であり、30％のみが断続的な（断続的な）障害であることがわかりました。 次に、行、列、またはブロック全体に影響するクラッシュなどの大規模なマルチビットクラッシュが、DRAMクラッシュ全体の40％以上を占めることがわかりました。 第三に、DRAM障害のほぼ5％が、データライン（DQ）やゲート（DQS）などのボードレベルの回路に影響することがわかりました。 最後に、ChipkillによりDRAMクラッシュによるシステムクラッシュ率が36倍減少することがわかりました。

この引用は、ECCに対する議論ではなく、特定のECCクラスであるChipkillに対する議論のように見えるため、いくぶん皮肉に思えます。 これはさておき、ジェフの投稿は、システマティックエラーがランダムエラーの2倍の頻度で発生することを示しています。 投稿では、システマティックエラーが発生したときにマシン上でmemtestを実行すると報告しています。



まず、2：1の比率は、ランダムエラーを単に無視するほど大きくはありません。 第二に、断食は、体系的なエラーは本質的に変化せず、しばらく経っても現れないというジェフの信念を暗示しています。 これは真実ではありません。 電子機器は、機械装置が磨耗するように磨耗します。 メカニズムは異なりますが、効果は似ています。 実際、チップの信頼性分析を他のタイプの信頼性分析と比較すると、障害をモデル化するために同じ分布ファミリを使用することが多いことがわかります。 第三に、ジェフの推論は、ECCがエラーを検出または修正するのを助けることができないことを暗示しています。これは間違っているだけでなく、引用と直接矛盾しています。



それでは、これらのシステムエラーをキャッチするためにマシンでmemtestを実行する頻度と、どれだけのデータ損失を生き残る準備ができているのでしょうか。 ECCの主な用途の1つは、エラーを修正することではなく、エラーを通知することです。そのため、「サイレント破損」が発生する前に機器を交換できます。 memtestを実行するために毎日マシン上のすべてを閉じることに誰が同意しますか？ これは、ECCメモリを購入するよりもはるかに高価です。 また、メモリテストの実行を説得できたとしても、memtestはECCが検出できるほど多くのエラーを検出しません。



約1,000台の車両を所有する会社で働いていたとき、データの整合性をチェックするときに奇妙な障害が発生していることに気付きました。約6か月後、一部のマシンで障害が発生する可能性が他のマシンよりも高いことに気付きました。 これらの障害は非常にまれであり（平均して週に数回）、情報を蓄積して何が起こっているのかを理解するのに長い時間がかかりました。 理由が分からないまま、ログを分析して、エラーがビットを反転する（高い確率で）孤立したケースに起因することを理解することも簡単ではありませんでした。 幸運なことに、使用したプロセスの副作用として、チェックサムが別のマシンの別のプロセスで異なる時間に計算されたため、エラーが結果を歪めず、この損害をチェックサムに拡大できませんでした。



メモリ内のチェックサムで自分自身を保護しようとしている場合、本当に異常な計算を行わない限り、すでに破損したデータに対してチェックサム操作を実行し、不正なデータに対して正しいチェックサムを取得する可能性が高くなります。独自のチェックサムを与えます。 また、バグの修正に真剣に取り組んでいるのであれば、おそらくまだECCを使用しているでしょう。



いずれにせよ、分析が完了した後、memtestは問題を検出できないことがわかりましたが、貧弱なマシンのRAMを交換すると、エラー率が1桁または2桁減少しました。 ほとんどのサービスには、私たちが持っていた種類のチェックサムはありません。 これらのサービスは破損したデータを永続的なストレージに静かに書き込むだけであり、クライアントが苦情を申し立て始めるまで問題を認識しません。

3.ハードウェアの開発のおかげで、エラーは非常にまれになりました。

投稿内のデータは、そのようなステートメントには不十分です。 RAMの使用量が増加し、指数関数的に増加し続けると、データ破損の頻度を実際に減らすために、RAM障害が指数関数的に大きく減少することに注意してください。 さらに、切りくずが減少し続けると、要素が小さくなり、2番目の段落で説明した摩耗の問題がより適切になります。 たとえば、20 nmテクノロジーでは、DRAMコンデンサーはどこかに50個の電子を蓄積でき、この数は減少傾向を維持しながら次世代のDRAMでは低くなります。



Atwoodが引用した2012年の調査では、ランダムに選択された10個の故障したノード（6％のノードに少なくとも1つの故障があった）で修正されたエラー（すべてのエラーのサブセット）のグラフがあります：









図 1.ランダムに選択されたノードの毎月のエラーを修正しました。 エラーの数は、各ノードで発生した障害の種類を示します。



障害のある一般的なノードのエラー数は1万から1万です。これは、ECCメモリが不要であると述べる投稿から慎重に選択された調査です。 ここでは、RAMが16 GBのみのノードが考慮されていることに注意してください。これは、最新のサーバーよりも1桁小さく、現在のプロセステクノロジーよりもノイズの影響を受けにくい古いプロセステクノロジーで実施されました。



信頼性の問題に対処するのに慣れていて、FIT値（故障率の単位）を知りたいだけの場合：この研究は、FIT値が0.057-0.071メガビットあたりのクラッシュであることを示しています（Atwoodの声明に反して、これは驚くほど低い数字ではありません） ）



0.057に等しい最も楽観的なFIT値を取得し、最大のRAMを持たないサーバーについて計算すると（ここで128 GBを使用します。現在表示されているサーバーには通常128〜1.5 TBのRAMがあるため）その後、各サーバーの期待値0.057 * 1,000 * 1,000 * 8,760 / 1,000,000,000 = 0.5の障害を取得します。 これはエラーではなくクラッシュを指すことに注意してください。 上記のグラフは、障害が月に数百または数千のエラーを簡単に引き起こす可能性があることを示しています。 また、調査の開始時にエラーのないノードがいくつかありますが、エラーは後で表示されることに注意してください。



Sun / Oracleは、数十年前にこれに真剣に直面していました。 現在起こっているように、DRAMのトランジスタとコンデンサは小さくなり、メモリ使用量とキャッシュは現在も増加しています。 一方では、一時的な中断に対する耐性が低く、製造がより困難な、絶えず減少するトランジスタに直面し、他方では、内蔵キャッシュの増大に伴い、サーバーベンダーの大多数がECCをキャッシュに導入しました。 サンは、ECCを使用せずに数ドル節約することにしました。 直接的な結果として、Sunの多くの顧客が定期的なデータ破損を報告しました。 その結果、Sunは数年を費やして新しいECCキャッシュアーキテクチャを開発し、チップを交換するために顧客にNDAに署名することを強制しました。



もちろん、そのようなものを常に隠すことは不可能であり、それらが表面化したとき、Sun が使用条件でベンチマークの禁止を導入してパフォーマンスの低下を隠そうとした場合と同様に、信頼できるサーバーを作成するというSunの評判は大きな打撃を受けました。



もう1つ注意してください。ECCの支払いには、ECCメモリだけでなく、より良い品質の部品（プロセッサ、ボード）の支払いも含まれます。 これはディスク障害の頻度で簡単に見ることができ、多くの人が個人的な観察でこれに気づいていると聞きました。



私が覚えている限り、アンドレアとレムジのグループは数年前にSIGMETRICSドキュメントをリリースしましたが、SATAドライブの読み取りエラーの確率はSCSIドライブの4倍であり、隠されたデータ破損の可能性は10倍高いことを示しました。 この比率は、同じメーカーのディスクを使用している場合でも維持されました。 SCSIインターフェースはSATAインターフェースよりも信頼性が高いと考える特別な理由はありませんが、これはインターフェースに関するものではありません。 クライアントコンポーネントと比較して、信頼性の高いサーバーコンポーネントを購入することについて話している。 おそらく、ドライブの信頼性に特に関心がないのは、チェックサムにすべてがあり、損傷を見つけるのは簡単だからですが、検出するのがより困難な違反がいくつかあります。

4. ECCメモリが非常に重要な場合は、サーバーだけでなくどこでも使用されます。

この議論を少し言い換えれば、「この機能がサーバーにとって本当に重要な場合、それは非サーバーでも使用される」と言えます。 この引数は、かなり大量のサーバーハードウェアに適用できます。 実際、これは大規模なクラウドソリューションプロバイダーが直面する最も不快な問題の1つです。



ほとんどのコンポーネントを適切な価格で入手するのに十分なレバレッジがあります。 しかし、交渉は、複数の実行可能なサプライヤーが存在する場合にのみ判明します。



実行可能な競合他社が存在しない数少ない分野の1つは、中央処理装置とビデオアクセラレータの製造です。 大規模なサプライヤにとって幸いなことに、彼らは通常、ビデオアクセラレータを必要とせず、多くのプロセッサを必要とします-それはずっと前に起こりました。 プロセッササプライヤによるサーバー市場への参入は何度か試みられましたが、最初からこのような試みには常に致命的な欠陥があり、運命が明らかになりました（そして、これらは多くの場合、少なくとも5年を必要とするプロジェクトです。つまり、自信なしに多くの時間を費やす必要がありました成功）。



Qualcommの取り組みには多くのノイズがありましたが、Qualcommの担当者と話をすると、現時点で作ったチップは基本的にテスト用であると言われます。それは、QualcommがIBMから誘い込んだすべての専門家からサーバーチップの作り方を学ぶ必要があり、次のチップが競争力のある最初のチップになることを望んでいたからです。 Qualcomm、および優れたサーバーコンポーネントを作成するためのARMの取り組みには大きな期待がありますが、これらの取り組みはまだ望ましい結果を生み出していません。



現在のARM（およびPOWER）オプションのほとんど完全な不適合（Appleの印象的なARMチップの仮想オプションを除く）は、1ドルあたりのパフォーマンスTCO（TCO）に関してほとんどのサーバーワークロードに当てはまりません。別の出版物。しかし、事実、Intelには市場の地位があり、サーバー機能に対して最高の料金を支払うことができます。そしてIntelはそれをします。さらに、いくつかの機能は、数ギガバイトのRAMと数ワットのエネルギー収支を備えたモバイルデバイスよりもサーバーにとって本当に重要です。モバイルデバイスからは定期的なクラッシュと再起動が依然として予想されます。

おわりに

ECC RAMを購入する必要がありますか？それは多くに依存します。サーバーの場合、これはおそらくコストを考慮すると良いオプションです。費用対効果の分析を行うことは実際には困難ですが、隠れたデータの破損による損害や開発者が断続的な障害を追跡するために半年の時間を失うリスクを判断することは非常に困難であり、それらがECCなしのメモリ使用量に起因することを発見するだけです



デスクトップコンピューターの場合、ECCのサポーターでもあります。ただし、定期的なバックアップを行わない場合、ECCメモリよりも定期的なバックアップに投資する方が便利です。また、ECCを使用しないバックアップがある場合、破損したデータをメインストレージに簡単に書き込み、これらの破損したデータをバックアップに複製できます。



, , , , / / . , (, , -) , . , ; , , , , , .



1。楽しい例の1つは（少なくとも私にとっては）魔法の自己修復ヒューズリンクです。多くの実装がありますが、ある種の抵抗器としてチップ上のヒューズ付きジャンパを想像してください。電流を流すと、接続が確立されます。電流が高すぎると、抵抗器が温まり、最終的に崩壊します。これは通常、チップ上の要素を無効にするため、またはクロック周波数の設定などのアクションのために使用されます。基本原則は、ジャンパーを焼き付けた後、ジャンパーを元の状態に戻す方法がないことです。



昔、半導体デバイスのメーカーがありましたが、その製造プロセスに少し急ぎ、特定の技術世代で許容範囲をいくぶん下げました。数か月（または数年）後、そのようなジャンパーの両端間の接続が再表示され、復元される可能性があります。運が良ければ、そのようなジャンパーはクロック周波数逓倍器の高ビットのようなものになり、変更されるとチップが無効になります。運が悪ければ、隠されたデータの破損につながります。



さまざまな企業の多くの人々から、このメーカーのこの技術世代の問題について聞いたので、これらは孤立したケースではありませんでした。面白いと言うとき、この話をバーで聞くのは面白いということです。ジャンパーの設定は無意味であり、チップをやり直してリリースを3か月延期する必要があるため、1年のテストの後、一部のチップが機能しないことを見つけるのは面白くありません。ちなみに、ヒュージブルジャンパの復元を伴うこの状況は、ECCを使用してその重大度を平滑化できるエラーのクラスの別の例です。



これはGoogleの問題ではありません。私がこれに言及するのは、私が話す人の多くが、ハードウェアの故障の可能性に驚いているからです。



2。本全体を詳しく調べたくない場合は、必要なフラグメントを次に示します。



ソフトウェアレベルで一連の障害に耐えることができるシステムでは、ハードウェアの最小要件は、この部分の障害が常に検出され、ソフトウェアインフラストラクチャがそれらを制限し、適切な回復アクションを実行できるように、適切なタイミングでソフトウェアに報告されることです。ハードウェアがすべての障害に明示的に対処する必要はありません。これは、そのようなシステムの機器を、エラーを修正する可能性なしに設計する必要があるという意味ではありません。エラー修正機能をリーズナブルな価格または複雑さで提供できる場合はいつでも、そのサポートはしばしば報われます。つまり、ハードウェアエラーの修正に非常にコストがかかる場合、システムは安価なバージョンを使用でき、検出機能のみが提供されます。最新のDRAMシステムは、非常に低い追加コストで強力なエラー訂正を提供できる状況の好例です。ただし、ハードウェアエラーを検出する要件を緩和することははるかに複雑になります。これは、各ソフトウェアコンポーネントが自身の正しい実行を検証する必要性を負担することになるためです。歴史の初めに、GoogleはDRAMのパリティが不足していたサーバーを処理しなければなりませんでした。 Web検索インデックスの作成は、基本的に、長時間にわたって複数のマシンを使用する非常に大規模なソート/マージ操作で構成されます。2000年に、Googleの毎月のWebインデックスの更新の1つは、チェックされたリクエストのサブセットが明らかにランダムにドキュメントを返したことを発見したときに、予備チェックに失敗しました。新しいインデックスファイルでのいくつかの調査の後、データ構造の特定の場所でビットをゼロに固定することに対応する状況が明らかになりました。これは、障害のあるDRAMチップを介して大量のデータをストリーミングすることによる悪影響です。この問題が再発する可能性を最小限に抑えるために、インデックスデータ構造に一貫性チェックが追加され、この種の問題はそれ以上発生しませんでした。ただし、この方法では、すべてのメモリ位置がチェックされるわけではないため、インデックス作成パスでのエラーの100％検出が保証されないことに注意してください。たとえば、確認せずに残ります。これは、インデックスデータ構造が計算に関与する他のすべてのデータよりも非常に大きいため、これらの自己監視データ構造の存在により、欠陥のあるDRAMを備えたマシンが特定され、クラスターから除外される可能性が非常に高いためです。 Googleの次世代マシンはすでにメモリにパリティ検出を含んでおり、ECCメモリの価格が競争力のあるレベルに下がるとすぐに、後続のすべての世代がECC-DRAMを使用しました。Googleの次世代マシンはすでにメモリにパリティ検出を含んでおり、ECCメモリの価格が競争力のあるレベルに下がるとすぐに、後続のすべての世代がECC-DRAMを使用しました。Googleの次世代マシンはすでにメモリにパリティ検出を含んでおり、ECCメモリの価格が競争力のあるレベルに下がるとすぐに、後続のすべての世代がECC-DRAMを使用しました。