Linuxサーバーのシンプロビジョニングのベストプラクティス（VMware）

私は約20台のLinuxマシンをセットアップしており、それぞれに約30〜150ギガバイトの顧客データがあります。おそらく、一部のマシンではデータのサイズが他のマシンより大幅に速くなります。これらは、VMware vSphereクラスター上の仮想マシンです。ディスクイメージはSANシステムに保存されます。

個々のマシンを簡単に拡張できるようにしながら、ディスク領域を節約するソリューションを見つけようとしています。

理論的には、マシンごとに大きなディスクを作成し、シンプロビジョニングを使用します。各ディスクは必要に応じて拡大します。ただし、データがわずか50 GBで、書き込み回数が非常に少ない500 GBのext3ファイルシステムでも、ディスクイメージが容易に増加します。時間の経過とともに250 GB。それとも私はここで何か間違っているのですか？（私がGoogleでこの件についてほとんど何も見つけなかったのには驚きました。ところで、serverfault.comにはシンプロビジョニングタグさえありません。）

現在、私は大きなシンプロビジョニングされたディスクを作成することを計画していますが、それらに小さなLVMボリュームを使用しています。例：500 GBディスク上の100 GBボリューム。そうすれば、オンラインでも、必要に応じてLVMボリュームとファイルシステムのサイズをより簡単に拡張できます。

今実際の質問のために：

これを行うより良い方法はありますか？（つまり、ダウンタイムなしで必要に応じてデータサイズを拡大するため。）

可能な解決策は次のとおりです。

• 同じスポットを何度も占有しようとするシンプロビジョニング対応のファイルシステムを使用しているため、画像サイズが大きくなりません。

• パーティションの空き領域を再利用する簡単な方法を見つける（再間引き？）

• 他に何か？

おまけの質問：現在の計画に同意する場合、ディスク（pvcreate /dev/sdX1とpvcreate /dev/sdX）にパーティションを作成することをお勧めしますか？パーティションのないrawディスクを使用することは慣習に反すると思いますが、必要に応じてディスクを拡張することは少し簡単になります。これはただの好みの問題ですよね？

シンプロビジョニングを正しく理解している場合、VMFSファイルシステムの増加を綿密に監視しておらず、VMDKがVMFSボリュームをいっぱいにしてしまうと、本当に問題が発生する可能性があります。テストで、シンプロビジョニングされたディスクは、利用可能なスペースをすぐにいっぱいにするために大きくなる傾向があり、OS内で空いている可能性のあるスペースを再利用できないことがわかりました。

もう1つのオプションは、現在の使用量と予想される急増の急増に対応できる十分なサイズのVMDKファイルを作成し、アプリケーションデータの使用量が増えるにつれてVMDKファイルを追加することです。新しいVMDKファイルをライブでVMに追加できます。再スキャンするだけです（エコー "---"> / sys / class / scsi_host / host？/ scan）。新しいディスクをパーティション分割してLVMに追加し、ファイルシステムをすべてライブで拡張できます。このようにして、各VMに割り当てられているスペースの量を常に認識しており、ゲスト内部から誤ってVMFSをスペース不足で実行することはありません。

ディスクがLVMでのみ使用される場合、パーティションを作成するかどうかに関しては、常にパーティションを作成します。ディスクをパーティション分割すると、マシンの起動時に偽のパーティションテーブルに関する警告が表示されなくなり、ディスクが割り当てられていることが明確になります。これは少しブードゥーですが、パーティションとファイルシステムが基盤となるストレージとブロックアラインメントされていることを確認するために、パーティションを64から開始することも確認してください。通常は簡単に比較できるものがないため、検出と分類は困難ですが、OSファイルシステムが基盤となるストレージと適切に調整されていない場合は、基礎となるストレージ。

私が考えることができる最良の提案は、物理ボリューム、ボリュームグループ、および論理ボリュームでLVMセットアップを作成し、それらの論理ボリュームをiSCSI経由でVMのファイルシステムとしてマウントすることです。

これにより、論理ボリュームのサイズを変更できます。その後、iscsiデーモンと仮想マシンソフトウェアを再起動し、新しいサイズパラメーターがあることを確認してから、ゲストのファイルシステムのサイズを変更して、一致するようにします。

パーティション分割は、標準のhddと同じように機能します。これは、仮想マシンゲストにLVが表示される方法です。

編集：これを気にしないでください、私はあなたがLinuxの下でVMwareを実行しているのではなく、VMwareの下で実行しているという誤った印象を得ました。

私はそれがVMwareでどのように機能するか知りませんが、Redhat RHEV-M / RHEV-Hは可能であり、RHEL 4.8から5.Xをサポートし、勝利2k3 R2と勝利2k8を同時にサポートします。詳細についてはhttp://studyhat.blogspot.com/2010/05/rhev-for-servers-22-installation-and.html

異なる提案：すべてのユーザーデータを保持するファイルサーバーをセットアップします。

もちろん、そのファイルサーバーは、オンラインの容量管理のためにLVMで管理する必要があります。

必要に応じて、SAN内のファイルサーバーの1つのコピーと外部などの2つ目のコピーでha-setup（drbd +ハートビート）を作成できます。（パラノイアのために）

クライアントはLinuxベースであるため、Sambaより高速であると言われているNFSを使用できます。FileServerを使用すると、一元化されたバックアップ戦略と一元化されたストレージ使用状況の監視が可能になります。そして、あなたのシンプロビジョニングの質問に関して：

意図したとおりにLVMセットアップを作成します（例では、500gb PV上の100gb LV、VMが必要とするストレージの合計と一致する数を変更するだけです）。各VMで個別に行う予定であったので、必要に応じてこのLVを拡張します。ただし、ファイルサーバーで一度だけ実行してください。VMがストレージの使用量を減らすたびに、そのスペースがすべてのVMで使用可能になります;-)

必要に応じて、または必要に応じてファイルサーバーに割り当てを使用して、単一のVMがファイルサーバーをいっぱいにしないようにします。

ボリュームを使用している仮想マシンをシャットダウンせずにボリュームを拡張できますか？私は通常これを行いますが、ストレージのセットアップがどのようなものか、VMwareがどのように複雑化するのかはわかりません。できれば、これは

1）プロビジョニングをシン化しないでください。各ボリュームを必要と思われるサイズにします。2）パーティションを使用しないでください。すべてのファイルシステムを独自のボリュームにします。3）事前にボリュームのサイズを変更できるように、ファイルシステムの増加を監視します。

ボリュームを増やすときが来たら

1）SANまたはVMwareで、ボリュームを拡張するために必要なことをすべて実行します。2）Linuxでを実行します。EXAMPLE echo 1 > /sys/block/EXAMPLE/device/rescanは/ sys / block /の下のデバイス名です。3）Linuxでを実行します。EXAMPLE resize2fs /dev/EXAMPLEは/ devの下のデバイス名です。

このアプローチは私にはうまく機能しています。私はシンプロビジョニングとLVMを使用したアプローチを検討しましたが、それでもうまくいくと思います。

LVMルートを選択する場合は、ディスクをパーティション分割しないことをお勧めします。おっしゃったように、パーティションテーブルがないと、仮想ディスクを簡単に拡張できます。パーティションテーブルがない場合は、pvresizeを実行するだけで、物理ボリュームが増加したことをLinuxが認識します。パーティションテーブルを使用する場合は、ファイルシステムのマウントを解除し、パーティションテーブルを削除して、パーティションテーブルを再作成してから、pvresizeを実行する必要があります。これはかなり多くの作業であり、ダウンタイムが必要です。