サーバーに複数のディスク (ボリューム) を用意することがクラウドのベスト プラクティスですか?

Question

の中に昔な日々物理サーバーの場合、ホストされているアプリケーションがいかに単純であっても、サーバーには常に少なくとも 2 つのディスク (ボリューム) があることが (少なくとも私が働いていた場所では) 良い習慣と考えられていました。

1 つのディスクはオペレーティング システム (OS) 用、もう 1 つのディスクはアプリケーション用です。これにはいくつかの理由があります。

1. アプリケーションがディスクをいっぱいにしたり、I/O を大量に使用したりしてディスクを破壊した場合でも、通常はログオンして何が起こっているかを確認でき、OS はイベントをログに記録し続け、何が起こったかを知らせることができます。
2. これにより、単一のボリュームから利用可能な I/O を競合することで OS がアプリケーションのパフォーマンスに影響を与えることがなくなりました。
3. バックアップ/復元では、OS を再構築できるため、アプリケーション ディスクのみを心配すればよいことになります。
4. これは OS に影響を与えないため、アプリケーション ディスクは管理 (マウント解除など) できます。

デフォルトでは、クラウド サーバーにはディスクが 1 つしかありません。このことから、この複数ディスク アプローチがクラウドでも意味があるかどうかについて考えさせられました。上記の点を考慮すると、(1)、(3)、(4) はおそらく依然として当てはまりますが、(2) はディスクが仮想的であるため、当てはまりにくくなります。つまり、ディスクはクラウド ベンダーが管理するストレージ サブシステムにマッピングされており、その方法は私にはわかりません。

では、このベストプラクティスはクラウドでも従う価値があるようですね?

それとも、クラウド環境で複数のボリュームを使用することがそれほど重要ではない理由を見逃しているのでしょうか?

Answer 1

コンピュータをサービスとしてレンタルしても、個別のデータ ディスクを使用するという決定に大きな変化はありません。

もちろん、デフォルトを変更することもできます。そうでなければ、インスタンスに追加のディスクを作成して追加するための API が存在する理由はありません。

ディスクが 1 つの方が管理が簡単です。特に、インスタンスが OS とアプリケーションのインストールであり、動的なデータがあまりない、比較的静的なイメージの場合に便利です。

ファイル システムがいっぱいになるのを防ぐことは依然として有用です。ただし、複数の物理ディスク以外のソリューションも可能です。LVM を使用して論理ボリュームを分離します。または、一部のインスタンスにデータ ファイルが増えないように、ログ記録またはメッセージングを集中化します。

IOPS とサイズのクォータを超過すると、複数のディスクを論理ボリュームに結合する必要がある場合があります。(物理アレイが不明な場合でも、少なくともクラウドではクォータが明確に定義される傾向があります。) スケールアップ データベースが存在します。

個別のデータ ボリュームにより、ブロック レベルのトリックが可能になります。データベース インスタンスの OS のメジャー アップグレードを想像してください。ただし、レプリケートするセカンダリ ストレージは存在しません。アップグレードされたインスタンスを準備しますが、データはありません。ダウンタイム中に、データ ボリュームをマウント解除してデタッチし、新しいインスタンスに提示してマウントします。アップグレードが高速で、データのコピーやボリュームの 2 番目のコピーは必要ありません。