トムズは細くするべきです

3Par InServアーキテクチャに関する投稿へのコメントでは、3Parシン再生メカニズムがどのように実装されているかを詳しく説明するように求められました。 このブログを管理する上で、おそらくアプリケーションでの作業が最も楽しい部分なので、喜んでお知らせします。



まず、実際に薄い再生が必要な理由を見てみましょう。 3Parはディスクアレイの他のベンダーに続き、システムでシンプロビジョニングテクノロジーを使用しました。これにより、ディスクリソースの仮想プールからアプリケーションに容量を割り当てることができます。 同時に、割り当てられた仮想容量は物理容量よりもはるかに大きくなる可能性があるため、アレイの購入時にディスクを大幅に節約できます。



良い決断。 しかし、問題があります。 アプリケーションは、この仮想容量​​の一部を解放し、そしてそれは彼がこの遊離する仮想容量に準拠した物理層ディスクで、余分な仮想容量を割り当てられていることが判明した場合は、まだこのアプリケーションに残り、他のアプリケーションに転送することはできません。



たとえば、このシナリオを考えてみましょう。ホストファイルシステムには100 GBのデータが含まれており、アレイディスク上の仮想ボリュームから同じ容量が割り当てられます。 合計サイズが10 GBのファイルのグループを削除した場合、アレイはこの削除を検出できず、100 GBがそのファイルシステムに割り当てられたままになります。



古いファイルの代わりに同じボリュームの新しいファイルを記録する場合、ファイルシステム自体のサイズは同じであるが、追加の10 GBのディスク容量を割り当てる必要があります-100 GB。 その結果、薄いボリュームは徐々に成長し、脂肪になります（脂肪ボリューム）。



この問題を解決するために、3ParはInServオペレーティングシステムにThin Persistence機能を追加しました（無料翻訳-スポーツ形式でのボリュームの維持）。 Thin Persistenceはリアルタイムで動作し、データを分析してからシンボリュームに書き込まれます。 ホストは、書き込みデータは、関数は、（ジャムや空き容量データを示している）すべてゼロからなるブロックを探し、次いで、仮想容量の空きプールにブロック部16Kを返します。 ヌル検索機能は専用の3Par ASIC Gen3チップに組み込まれているため、Thin PersistenceはInServ Storage Serverアレイの動作を遅くしません。



シンコピー再生機能は、同様の方法で機能します。 違いは、ファイルではなくスナップショットの削除により発生するボリュームの肥厚に苦労していることです。 スナップショットが削除されると、それに割り当てられた仮想ボリュームの容量が仮想プールに戻され、他のボリューム間で再配布できます。



3PARは、シン・プロビジョニング技術のパイオニアとして、ディスクアレイのメーカーの中で最初は、Veritas Storage Foundationのバージョン5以上のサポートシン再生API-インタフェースを実装すると言うことは価値があります。 それらの助けを借りて、ホスト自体で実行されているVxFSファイルシステムは、ファイルの削除について（WRITE SAME SCSIコマンドを使用して）ディスクアレイに通知するため、InServ Storage Serverアレイは、ゼロのブロックを検索せずにこれらのファイルに割り当てられた容量を見つけることができます（ 詳細はこちら ）。



また、Oracleの3PARユーティリティOracle自動ストレージ管理（ASM）ストレージと一緒に開発された埋立（ディスクアレイInServストレージサーバにコンテナDBMSのOracle Database 10gおよび11gを解放するために、ここで詳細 ）。



それが面白かったと思います。