低速なOSドライブ、高速なデータドライブ

長年にわたって、人々がオペレーティングシステムパーティションには高性能で高信頼性のデータストレージを選択しながら、重要なデータストアには低速な「コスト効果の高い」ストレージを選ぶ傾向があることを発見しました。これがいかに頻繁に起きているかに驚かされます。そして今では、ハイパーバイザーの登場により、同じ行動がそこでも繰り返されているのを見ています。これにより以前からある問題がさらに深刻化しています。

今日の多くのシステムでは、システムのすべてのコンポーネントが共有する単一のストレージアレイしか扱いません。これらのケースでは、ストレージシステムのパフォーマンスバランスが崩れるという問題に直面しません。これはこのアプローチの大きな利点の一つであり、非常に強く推奨される主な理由です。すべてのパフォーマンスは共有プールにあり、パフォーマンスを必要とするコンポーネントがそれにアクセスできます。

多くのケースで、パフォーマンスや信頼性設計の向上を試みるためか、技術的な必要性からか、人々がストレージアレイを分割してハイパーバイザーとオペレーティングシステムを一方のアレイに、データをもう一方に置いているのを見かけます。しかし私が驚くのは、ハイパーバイザーやオペレーティングシステム専用のアレイが、容量は非常に大きく、パフォーマンスは極めて高いことが多いことです。15,000 RPMのスピンドルや高価なソリッドステートドライブを使用していることさえあります。ほぼ常に（1998年の一般的な標準通り）RAID 1で構成されています。

ここで理解しなければならないのは、オペレーティングシステム自体はストレージIOの要件が事実上ないということです。主にシステムロギング用にわずかな量があるだけで、必要なのはそれだけです。オペレーティングシステムのパーティションはほぼ完全に静的です。必要なコンポーネントはメモリにロードされ（主にブート時に）、その後は再びアクセスされません。ロギングが必要な場合でも、これらのログは多くの場合、中央ロギングシステムに送られ、システムストレージエリアには送られないため、そのニーズを軽減または完全になくします。

ハイパーバイザーではこの効果はさらに顕著です。ハイパーバイザーは従来のオペレーティングシステムよりもはるかに軽量でロバストではないため、組み込みシステムのように振る舞い、多くの点で実際に多くのケースで組み込みシステムです。ハイパーバイザーはシステムブート時にメモリにロードされ、システムの実行中はそのメディアがほとんど必要とされません。ただし時にはロギングの際に必要とされることがあります。ハイパーバイザーは物理サイズが小さいため、ストレージから完全なハイパーバイザーを完全に読み取るために必要な合計時間は非常に小さく、非常に低速なメディアでさえも、合計サイズが非常に小さいため短時間です。

これらの理由から、ストレージパフォーマンスはオペレーティングシステム、特にハイパーバイザーにとってほとんどまたはまったく重要ではありません。高速ストレージと低速ストレージの違いは実際にはシステムのブート時間にしか影響を与えず、1秒か30秒かの違いはほとんど気づかれないでしょう。いつシステムの起動時に数秒追加されたことに誰かが気づくでしょうか？ほとんどの場合、起動は計画されたメンテナンス期間中の自動化された定期的なシステム再起動で多くても週に1回起きるか、緊急時にのみオフラインになるシステムでは非常に稀に、時には数年に1回だけ起きる稀なイベントです。考えうる最も低速なストレージシステムでさえ、この役割に必要以上にはるかに速いのです。

低速なストレージでさえ、システムロギングアクティビティに必要な速度の何倍も速いのが一般的です。ロギングが非常に集中する稀なケースでは、この問題に対処する多くの選択肢があります。最も明白で一般的な解決策は、オペレーティングシステムやハイパーバイザーが使用するドライブアレイ以外のドライブアレイにログを送ることです。これは非常に簡単な解決策であり、それが正当化されるケースでは最終的に非常に実用的です。もう一つの一般的で非常に有用な解決策は、ローカルデバイスにログを保持せず、Splunk、Loggly、ELKなどのリモートログ収集ユーティリティに送ることです。

ほとんどの人がオペレーティングシステムやハイパーバイザーについて持つもう一つの主な懸念は信頼性です。多くの場合、しばしば取り替えのきかないデータよりも、これらの比較的重要でないシステムの側面を保護することに多くの努力を集中する傾向があります。しかし、オペレーティングシステムとハイパーバイザーは、必要に応じてクリーンインストールと手動再設定を使用してゼロから簡単に再構築できます。失われる可能性のある詳細は、一般的に再作成するのが比較的些細なことです。

もちろんこれは、これらのシステムファイルシステムをバックアップすべきでないということではありません（ほとんどの場合、当然バックアップすべきです）。しかし、バックアップが失敗した場合に備えて、OSパーティションやファイルシステムの損失が真の悲劇をもたらすことは稀であり、不便なだけです。元のデータへのアクセスなしにほぼすべてのケースで回復する方法があります。ただし、「データ」ファイルシステムが別である限りです。そして、オペレーティングシステムとハイパーバイザーの性質上、変更は稀なためバックアップは一般的に頻度を低くすることができ、場合によっては更新が適用された時のみ手動でトリガーされる可能性があります！

DevOpsとクラウドコンピューティングスペースの多くの現代的なシステムでは、オペレーティングシステムとハイパーバイザーのファイルシステムをシステムイメージまたは構成管理システムによってリモートで定義されるため、完全に使い捨て可能なものとして見なすことが非常に一般的になっています。これらのケースでは、特別なインタラクションなしにほぼ即座に再作成されるように設計されているため、データ保護やバックアップは必要ありません。システムは完全に自己複製します。これにより、システムファイルシステム保護の必要性がさらに些細なものになります。

総合すると、パフォーマンスの必要性の欠如と、主に単純な再作成によって処理される保護と信頼性の必要性の欠如を合わせると、私たちが一般的に想定するものとは非常に異なるニーズを持つシステムファイルシステムがあります。これはストレージに対して無謀であるべきだということではありません。システムが実行中にストレージ障害を避けることは依然として望んでいますし、不必要に再構築することは、それが壊滅的でないとしても時間とリソースの無駄です。したがって、慎重なバランスをとることが重要です。

もちろん、これらの理由から、オペレーティングシステムやハイパーバイザーをデータと同じストレージアレイに含めることが現在の一般的な慣行です。データファイルへのアクセスと同時にシステムファイルへのストレージアクセスの必要性がほとんどまたはまったくないため、OSの高速ブート時間が得られ、システムがオンラインになった後のデータアクセス時間に悪影響がありません。これは今日のシステム設計者がストレージの効率的な使用のニーズに取り組む主要な手段です。

オペレーティングシステムやハイパーバイザーをデータを保持するアレイから分離しなければならない場合（これはさまざまな理由でまだ起こる可能性があります）、一般的に低コストで合理的な信頼性を求めます。従来のストレージ（ローカルディスク）を使用する場合、これはオペレーティングシステムストレージに小型で低速、低コストの回転ドライブを使用することを意味し、一般的に単純なRAID 1構成です。実世界の例として、できる限り小さなサイズの5,400 RPMの「エコフレンドリー」なSATAドライブの使用があります。これらは消費電力が少なく、購入コストが非常に安価です。SSDと高速SASドライブは、無関係な保護のためのプレミアムコストと完全に無駄なパフォーマンスのために避けられます。

従来とは異なるストレージでは、多くのシステムの低優先度ストレージをレプリケートされない共有の低速アレイに統合する低コスト、高密度SANを使用することが一般的です。これは、ストレージ統合プロセスで必要なコスト削減を達成するのに十分な密度を達成できる、追加のアーキテクチャ設計を正当化できる大規模環境においてのみ効果的ですが、大規模環境ではこれは比較的容易です。SANブートデバイスはコスト削減のために多くのサーバーにわたって非常に低コストのアレイを活用できます。仮想空間では、これはOSバーチャルディスクに使用される低パフォーマンスのデータストアとデータバーチャルディスク用の高パフォーマンスプールを意味する可能性があります。これはブートSAN戦略と同じ効果を持ちますが、よりモダンな設定で、簡単にそれを達成するためにSANアーキテクチャを内部で活用できます。

最後に、そして最も劇的なのは、ハイパーバイザーをSDカードまたはUSBサムドライブにインストールすることがハイパーバイザーの一般的な経験則です。これは従来のオペレーティングシステムよりもはるかにパフォーマンスと信頼性のニーズが少ないためです。このような性質のドライブがシステムの実行中に故障した場合、ドライブはシステムが最初にブートした後には使用されないため、実際に何の問題もなく実行し続けます。問題が発見されるのは再起動時だけであり、その時点で二次SDカードやUSBスティックなどのバックアップブートデバイスを使用できます。これはVMware vSphereの公式推奨事項であり、MicrosoftのHyperVの代表者によって推奨されることも多く、HyperVのOEMベンダーを通じて公式にサポートされており、Xen、XenServer、KVMシステムに対しては推奨されることも多いですが、そこまで広くサポートされているわけではありません。ハイパーバイザーストレージにSDカードまたはUSBドライブを使用することは、仮想化サーバーを実質的に組み込みシステムに変えます。これはサーバーの必需品として従来のディスクを考えることに慣れているシステム管理者には不自然に感じるかもしれませんが、ルーターやスイッチのようなエンタープライズクラスの非常に重要なシステムが数十年持続し、まったく同じ理由でこのまったく同じ戦略を使用していることを覚えておくことが重要です。

SDカードまたはUSBドライブを使用したこの組み込みスタイルモードでのハイパーバイザーの一般的な戦略は、そのようなデバイスを2つ持つことです。これは実際に1つのSDカードと1つのUSBドライブで、それぞれにハイパーバイザーのコピーが入っています。一方のデバイスが故障した場合、2番目のデバイスにブートすることは従来のRAID 1システムとほぼ同等に効果的です。しかし、ほとんどの従来のRAID 1セットアップとは異なり、一度に一方のブートデバイスだけを更新し、2番目のブートデバイスを更新する前にプロセスをテストすることで、バージョン更新がうまくいかない場合に信頼性の高いテスト済みのフォールバックが残るシステム更新の比較的簡単なテスト手段も持っています。このプロセスは実際に、大型UNIXのRISCシステムで一般的で、ブートデバイスはしばしばローカルソフトウェアRAID 1セットで同様のプラクティスをサポートしていました。特にAIXとSolarisのサークルで一般的でした。

このアプローチがほとんどのハイパーバイザーシナリオのベストプラクティスである一方で、完全なオペレーティングシステムファイルシステムにも適用できない理由は実際にはありません。ただし、それはしばしばより多くの作業を伴います。特にLinuxとBSDなどのOSは、組み込み形式でのインストールに非常に適しており、少しの計画でSDカードまたはUSBドライブへのインストールに容易に対応できます。このアプローチはまったく一般的ではありませんが、適切な状況では技術的な理由がないわけではなく、非常に優れたアプローチとなり得ます。ただし、OSがハイパーバイザーの上ではなく物理的なハードウェアにインストールされるべきことはほとんどないという点を除いては。物理的なインストールが必要な場合には、このアプローチは非常に有効です。

ストレージシステムの設計と計画を行う際には、システムが実行されているときに読み取りと書き込みのパターンが実際にどのように見えるかを注意深く考えることを忘れないでください。そして、多くの従来のガイドラインが開発された時以来ストレージは劇的に変化しており、それらを開発するために使用されたすべての知識が今日もまだ適用されるとは限らないことを忘れないでください。どのストレージサブシステムがストレージパフォーマンスを使用しようとするかだけでなく、それらが互いにどのように相互作用するか（例えば、2つのシステムが同時にストレージアクセスを要求することが決してないのか、定期的に競合するのか）、そしてそのアクセスパフォーマンスが重要かどうかも考えてください。一般的なオペレーティングシステムの機能は、データベースサーバーでは非常に低速になっても悪影響を与えません。重要なのはデータベースにアクセスできる速度だけです。アプリケーションバイナリへのアクセスでさえ、一度メモリにロードされると、そこに留まりメモリ速度のみが継続的なパフォーマンスに影響するため、しばしば無関係です。

これはOSとデータストレージサブシステムを互いに分離することが推奨されることを示唆するためではありません。多くの場合そうではありません。過去にこれらのサブシステムを統合することが非常に頻繁にベストコースオブアクションであり、それが今も真実であることについて書きました。しかし、特定のストレージニーズを互いに分離することが理にかなっている多くの合理的なケースもあります。特に、高コストのストレージを特定のニーズに、低コストのストレージを他のニーズに専用化することでコストを下げられる大規模なシステムを扱う場合です。そのようなケースこそ、最も極端な場合を除いて、オペレーティングシステムとハイパーバイザーはパフォーマンスと信頼性の両方において最低優先度と見なされるべきだということを示したいのです。