冗長性がない方が信頼性が高い場合——冗長性の神話

リスクは難しい概念であり、与えられたシナリオを適切に評価するためには多くのトレーニング、思考、分析が必要です。リスク評価が非常に困難であるため、私たちはしばしばリスク分析の代わりに単純に基本的な冗長性を追加し、リスクを適切に軽減したと思い込んでしまいます。しかし、多くの場合これは当てはまりません。複雑性や追加の障害モードの導入は冗長性の追加に伴うことが多く、これらの新しい形の障害は冗長性が除去するよりも多くのリスクを追加する可能性があります。ストレージシステムはこのような意思決定プロセスに特に影響を受けやすく、障害に対して最も脆弱で保護することが最も重要なシステムがほとんどないため、残念です。

RAID は、総合的なリスク思考の欠如が奇妙な意思決定につながる可能性がある好例です。あまり珍しくないシナリオを見ると、ドライブ障害から保護するという目標が実際に、追加の冗長性が適用された場合でもリスクの増大につながる可能性があることがわかります。このシナリオでは、単一アレイで12台の3テラバイトSATAハードドライブで構成された12ドライブアレイを比較します。「最大容量とパフォーマンス」を得ながら「障害に対する適切な保護」を持つためにRAID 5を選択したという話を聞くことは珍しくありません。

ここでの考え方は、RAID 5 が単一ドライブの損失から保護し、それを交換できるため、二次ドライブが障害を起こす前にアレイが再構築されるというものです。これは理論上は素晴らしいことですが、36テラバイトのドライブ容量を持つこのサイズのアレイの実際のリスクは、人々が一般的に疑うような複数のドライブ障害からではなく、単一ドライブ障害後にアレイを確実に再構築できないことや、個々のドライブが障害を起こすことなくアレイ自体が障害を起こすことから来ています。二次ドライブが障害を起こすリスクは低く、存在しないわけではありませんが、かなり低いです。今日のドライブは非常に信頼性が高いです。一つのドライブが障害を起こすと、二次ドライブが障害を起こす可能性が高まりますが（よく記録されていることです）、このリスクが本当のリスク——失敗したリシルバー操作のリスク——から目を逸らさせないようにしたいと思います。

RAID 5 リシルバー操作中に私たちを怖がらせることが起こります。回復不能読み取りエラー（URE）が発生する可能性があります。それが発生すると、リシルバー操作は停止し、アレイは使用不能な状態に置かれ——アレイ上のすべてのデータが失われます。一般的なSATAドライブでは、URE の率は10^14、つまり12テラバイトの読み取り操作ごとに1回です。つまり、6テラバイトのアレイをリシルバーする場合、URE に遭遇して失敗する確率が約50%あります。50%の失敗確率は信じられないほど高いです。車が走るたびに50%の確率で車輪が外れるとしたら想像してみてください。つまり、10^14 URE SATAドライブを使用した小さな（今日の基準では）6テラバイトRAID 5アレイで、単一ドライブを失った場合、ドライブが直ちに交換されると仮定してもアレイが回復する確率は50%しかありません。これは二次ドライブが障害を起こすリスクを含まず、URE 障害のリスクのみです。また、リシルバー操作以外にドライブが完全にアイドル状態であると仮定しています。同時に他のタスクでドライブが使用されている場合、URE または二次ドライブ障害のいずれかの悪いことが起こる可能性は劇的に増加し始めます。

12テラバイトのアレイでは、リシルバー操作中に完全なデータ損失の可能性が100%に近づき始めます——つまり、その場合RAID 5には何の機能もありません。生き残る可能性は常にありますが、非常に低いです。6テラバイトでは、リシルバー操作を1発の弾と6つのチャンバーでのロシアンルーレットゲームに例えることができ、3回引く必要があります。12テラバイトでは6回引かなければなりません！それは良いオッズではありません。

しかし、私たちは12テラバイトのアレイについて話しているのではありません。36テラバイトのアレイについて話しています——これは大きく聞こえますが、今日では自宅でも、ビジネスはもちろん、誰かが簡単に持てるサイズです。すべての主要なサーバーメーカー、および低コストのストレージベンダーのほぼすべてが、この容量範囲で1万ドル未満のストレージシステムを今日製造しています。36テラバイトのアレイで単一ドライブ障害が発生したRAID 5アレイをリシルバーすることは、1発の弾、6つのチャンバーでロシアンルーレットをプレイし、引き金を18回引くようなものです！データはほとんど生き残れません。さらに、そのサイズのアレイをリシルバーするために必要な驚異的な時間を考えると、リシルバーウィンドウ中に二次ディスクが障害を起こすリスクがかなり重大な脅威になり始めます。一部のシステムでは、リシルバー時間が数週間または数ヶ月に及ぶという見積もりを見たことがあります。別のドライブを失うことができない状態で実行するには長い時間です。時間や日数で話している場合、リスクはかなり低いですが、依然として存在します。リシルバー操作は非常にドライブ集中的であるため、継続的な酷使が数週間または数ヶ月続く場合、障害率は劇的に上昇します。

このサイズのアレイでは、単一ドライブの損失はアレイ全体の損失を意味し、ドライブ障害の保護がまったくないと事実上想定できます。同じか、それよりも優れたパフォーマンスと同じか、それよりも優れた容量を持つRAID 0（ドライブ損失に対する保護もない）を見ると、RAID 5アレイに必要な12台のドライブのうち11台しか使用する必要がありません。これが意味することは、それぞれが年間約3%の障害確率を持つ12台のハードドライブではなく、11台しかないということです。それだけで、障害を起こすドライブが少ないため、RAID 0アレイの方が信頼性が高くなります。ドライブが少ないだけでなく、パリティブロックを書き込む必要も、リードバック時にパリティブロックをスキップする必要もなく、同じ利用率のRAID 0アレイの機械的な摩耗をわずかに低下させ、非常にわずかな追加の信頼性のエッジを与えます。11台のドライブのRAID 0アレイは12台ドライブのRAID 5アレイと同じ容量になりますが、スループットとレイテンシーがわずかに優れています。あらゆる面で勝ちです。さらに、追加のドライブが不要なためコスト削減になります。

ここで見えてくるのは、大きなアレイ（スピンドル数ではなく容量が大きい）では、RAID 0 が特定のシナリオでRAID 5を超えるということです。一般的なSATAドライブを使用する場合、これは自宅のパワーユーザーや多くの中小企業でも経験される容量で起こります。エンタープライズSATAドライブやSASドライブに移行すると、これが起こる容量数は非常に高くなり、今日は問題になりませんが、ドライブ容量がさらに大きくなるほんの数年後には問題になります。しかし、これは今日見られるサイズのRAID 5 がいかに危険であるかを浮き彫りにします。誰もがRAID 0の信じられないほどのリスクを理解していますが、RAID 5の問題がこれほど極端で、実際にRAID 0よりも信頼性が低い可能性があることを理解するのは難しい場合があります。

このサイズのアレイでは、リシルバー操作だけでRAID 5 がRAID 0よりも信頼性が低い可能性があることは始まりに過ぎません。このような大規模なアレイでは、リシルバー時間が非常に長くかかり、ドライブに多大な負担をかけるため、二次ドライブ障害が測定可能なリスクになり始めます。さらに、ドライブ障害が発生していない場合でもアレイ全体を破壊するためにリシルバーアルゴリズムを利用するアレイコントローラーエラーによる追加リスクがあります。RAID 0（またはRAID 1またはRAID 10）はリシルバーアルゴリズムを持たないため、この追加リスクに悩まされません。これらは定量化が難しいリスクですが、重要なのは、単純なシステムが最初からより信頼性が高かった場合に、より複雑なシステムを使用することで蓄積される追加リスクであるということです。

RAID 5 がRAID 0よりも信頼性が低い可能性があることを確立したので、RAID 0の明らかな危険性を指摘します。一般的に RAID は単独のハードドライブが障害を起こすリスクを軽減するために使用されます。単一のドライブが単純に障害を起こし、すべてのデータが失われることを誰もが恐れています。RAID 0は、冗長性のない複数のドライブの大きなストライプであり、単一ドライブが障害を起こすことによるデータ損失のリスクを複数のドライブにわたって倍増させ、どのドライブが障害を起こしてもすべてのドライブのデータが完全に失われます。したがって、上記の11ディスクの例では、11枚のディスクのいずれかが障害を起こすとすべてが失われます。これが単一のドライブを単独で使用するよりもはるかに危険であることは明らかです。

ここで指摘したいのは、冗長性は信頼性を意味しないということです。RAID 5のように何かが冗長であるからといって、冗長でないものよりも常に信頼性が高いという保証はありません。

私のお気に入りの例えは、竜巻が来たときの家を見ることです。一つのシナリオでは、レンガとモルタルで家を建てます。二つ目のシナリオでは、二つの冗長な家を建てますが、どちらも藁で作ります（建築業者は豚のようです）。竜巻（または大きな悪い狼）が来たとき、どちらが立っている家を残す可能性が高いでしょうか？明らかに一つのレンガとモルタルの家は、冗長な藁の家よりも大きな信頼性の優位性があります。冗長性は関係なく、最終的には信頼性が重要でした。

冗長性は定量化しやすいが、資格付けが難しいためしばしば誤解を招きます。冗長性は白か黒かの問題です：それは冗長ですか？はいかいいえ。シンプルです。信頼性はそれほど単純ではありません。信頼性は障害率と可能性についてです。統計と分析についてです。特にビジネスの人々にプロジェクトを売り込む際に、信頼性を意味のある方法で定量化することが難しいため、冗長性はしばしばこの複雑な概念のシンプルな代替品になります。

冗長性を信頼性の質問をそらすために使用するという概念は、非常に複雑な方法でサブシステムにも適用されます。「システム」を冗長にする代わりに、信頼性が高く低コストのサブシステムを冗長にして、サブシステムの冗長性がシステム全体に適用されるかのように扱うことが一般的になっています。最も一般的な例は、SANプロダクトのRAIDコントローラーです。冗長なSAN（つまり2つのSAN）を持つ代わりに、メーカーはしばしば通常のサーバーでは冗長でないその1つのコンポーネントを冗長にして、SANを冗長と呼びます——これは冗長性を含むSANを意味し、まったく同じことではありません。

良い例えは、冗長な車を持つことを意味する完全に動作する2台の車と、メインのウォーターポンプが障害を起こした場合に備えてトランクに予備のウォーターポンプを1つ持つ単一の車を比較することです。明らかに、予備のウォーターポンプは悪いことではありません。しかし、走行準備ができている二台目の車を持つことと比較して、車の故障に対する保護としては些細な量です。一方のケースでは、シャーシを含むシステム全体が冗長です。他方では、シャーシ内の1つの非常に信頼性の高いコンポーネントのみを冗長にしています。少なくとも、障害の可能性が高い車のコンポーネントである予備タイヤを持つことにさえ及んでいません。

RAID 5 の信頼性とシステム/サブシステムの信頼性の神話と同様に、SANとNASのような共有ストレージ技術は、特に仮想化に関して同じように扱われることが多いです。仮想化プロジェクトが実施され、単一の仮想化ホストが障害を起こすと多くのシステムが一度に失敗するという単一障害点を表しているとして、人々が本能的にパニックになるという一般的なシナリオがあります。

「単一障害点」という用語を使用することでパニック感を引き起こし、会話を誘導する優れた手段となります。しかし、私たちが好んでSPOFと呼ぶものは、可能な場合に削除したいものですが、すべてのシナリオで世界の終わりではないかもしれません。レンガの家について考えてみてください。それはSPOFです。2つの藁の家はそうではありません。しかし、一つのそよ風が信頼性の高いSPOFよりも早く冗長なソリューションを倒します。SPOFを探すことは、システムの脆弱点を見つける素晴らしい方法ですが、すべてのSPOFをすべてのシナリオで冗長にする必要があるとは感じないでください。ほとんどのビジネスは、多くのSPOFを持つことで最良の価値を見つけるでしょう。私たちの本当の目標は、適切なコストでの信頼性であり、冗長性は、見てきたように、信頼性の代替品ではなく、信頼性を達成するために使用できるツールに過ぎません。

仮想化する際に多くの人々が従う理論は、仮想化ホストを取り上げて「このホストはSPOFなので、2つ必要であり、透過的フェイルオーバーを可能にするために高可用性機能を使用する必要がある！」と言うことです。これは、主要な仮想化ベンダーが高価なHAアドオン製品を販売することで収益を上げ、次に大規模なストレージベンダーに所有されているという事実によって促進されています——したがって、不必要または危険な追加の共有ストレージを販売することは彼らにとって大きな金銭的な勝利であり、彼らが最初から仮想化スペースを支持してきた理由である可能性があります。共有ストレージを持つ冗長な仮想化ホストは素晴らしく聞こえますが、いくつかの理由で非常に誤解を招く可能性があります。

最初の理由は、最初のSPOFである仮想化ホストを除去することが新しいSPOF、つまり共有ストレージに置き換えられることです。これは何も達成しません。同等品質のサーバーと共有ストレージを使用していると仮定すると、リスクがどこにあるかを移動させただけで、その大きさは変えていません。ストレージシステムが障害を起こす可能性は、元のサーバーが障害を起こす可能性とほぼ同等です。しかし、SPOFをシェルゲームのようにシャッフルするだけでなく、さらにはるかに悪いことも行っています——連鎖した障害依存関係を導入しました。

元のシナリオでは、単一のサーバーがありました。サーバーが動作し続けていれば良く、障害を起こした場合は良くありませんでした。シンプルです。今では2つの仮想化ホスト、単一のストレージサーバー（SAN、NAS、その他何でも）、それらを接続するネットワークがあります。共有ストレージが障害を起こすリスクは、元のシナリオでの総システムリスクとほぼ同等であることがすでに確認されています。しかし今、ネットワークと2つのフロントエンド仮想化ノードの追加依存関係があります。これらの各コンポーネントは脆弱な共有ストレージよりも信頼性が高い（機械的なドライブを持つものはすべて脆弱になります）ですが、リスクが低いことが問題ではなく、問題はリスクが組み合わせ的であることです。

これら3つのコンポーネント（ストレージ、ネットワーク、またはフロントエンドノード）のいずれかが障害を起こすと、すべてが障害を起こします。これの解決策は、共有ストレージ自体を冗長にし、ネットワーク自体を冗長にすることです。十分な作業で、共有ストレージを追加したことで導入した脆弱性とリスクを克服できますが、共有ストレージ自体はリスク軽減の形ではなく、軽減されなければならないリスク自体です。複雑性のスパイラルが始まり、この新しいシステムを元の単一サーバーシステムの信頼性に引き上げるのに関連するコストは天文学的になる可能性があります。

この冗長性をすべて持った今、もう一つのリスクが心配されます。この冗長性のすべて、これらすべての動くパーツを管理するには、シンプルな単一サーバーを管理するよりもはるかに多くの知識、スキル、準備が必要です。シンプルなソリューションから非常に複雑なソリューションに移行しました。私自身の逸話的な経験では、このようなソリューションの本当の危険は、ハードウェアの障害からではなく、人的ミスから来ています。この新しいシステムが人的ミスで障害を起こすことを避けるためにほとんど何も行われていないだけでなく、人間が誤ってシステム全体——冗長性も含めて——を倒してしまう可能性のあるポイントを数え切れないほど追加しました。私は実際に目にしたことがあり、恐ろしい話を聞いたことがあります。システムが複雑であるほど、人間が誤ってすべてを壊してしまう可能性が高くなります。

IT プロフェッショナルとして、私たちは一歩引いて完全なシステムを見て、信頼性とリスクを考慮し、冗長性を信頼性を追求するためのツールとして単純に考えることが重要です。冗長性自体は万能薬ではありません。シンプルさも同様です。信頼性は取り組むことが難しい複雑な問題です。信頼性の問題をカバーアップすることから直面して解決することへと移行する上で、単純化された代替品を避けることは重要な最初のステップです。