従来のプールと比較したDynamic Poolの機能拡張と考慮事項

動的プールは、現在の需要に基づいてリソース割り当てを自動的に調整することで、従来のプールよりも優れた柔軟性と拡張性を提供します。これにより、リソース使用率の最適化、手動による管理作業の削減、変動するワークロード時の全体的な効率性の向上に役立ちます。

主な機能強化

• 自動スケーリング: リソースは、ワークロード要件に基づいて動的に追加または削除できます。
• リソース使用率の向上: 必要に応じてリソースを割り当てることで、オーバープロビジョニングとアンダー使用率を最小限に抑えます。
• 管理オーバーヘッドの削減: 容量計画とプール管理に必要な手動介入が少なくなります。
• パフォーマンスの強化: ワークロードは、需要のピーク時に追加のリソースにアクセスできるため、サービス レベルの維持に役立ちます。
• コストの最適化: 動的割り当てでは、リソースの消費と実際の需要を一致させることで、運用コストを削減できます。

考慮事項

• スケーリング レイテンシー: リソースのプロビジョニングまたはプロビジョニング解除は瞬時に行われない場合があり、ワークロードの応答性に影響を与える可能性があります。
• キャパシティ プランニング: 基盤となるインフラストラクチャには、動的な成長をサポートするのに十分な容量が必要です。
• モニタリング要件: スケーリング動作がワークロードのニーズに合致するようにするには、効果的なモニタリングとアラートが不可欠です。
• 構成の複雑さ: スケーリング ポリシーの初期セットアップとチューニングには、追加の計画とテストが必要になる場合があります。
• ワークロードの適合性: すべてのワークロード、特に予測可能で安定したリソース要件を持つワークロードでは、動的スケーリングから等しくメリットが得られるわけではありません。

全体として、動的プールは、リソース管理に対するより適応性が高く効率的なアプローチを提供しますが、メリットを最大化するには、綿密な計画、監視、ガバナンスが必要です。

この情報は、「マニュアル80903033:Dell Unityファミリーのプールの構成( バージョン5.x)」で参照されています。

動的プール

OEバージョン4.2.x以降を実行しているUnityオール フラッシュ モデルでは、Unisphere UIで作成された新しいプールすべてが動的プールです。また、Unisphere CLIおよびREST APIで作成された新しいプールは、デフォルトで動的プールです。動的プールでは、高度なRAIDテクノロジーが実装されます。動的プールでは、RAIDグループは、複数のドライブのドライブ エクステントに分散されます。また、必要なスペア スペースも、複数のドライブのドライブ エクステントに分散されます。ドライブで障害が発生すると、その障害ドライブのエクステントは、プール内のスペア スペース エクステントへ再構築されます。

動的プールは、次の点で従来のプールより優れています。

• 固定のスペアはないので、ドライブに無駄はありません。システム内のすべてのドライブをプールに追加できます。それにより、負荷は、追加のドライブに分散されるので、プール内のドライブの寿命が延びます。 
• 再構築の時間が、通常、従来のプールよりも大幅に短くなっています。動的プールのスペア容量が、1台のホット スペア ドライブに集中するのではなく、複数のドライブに分散されるため、ドライブで障害が発生したときに、より多くのドライブが再構築プロセスに関与します。 
• 通常、必要な容量に基づいて、プールを拡張できます。たとえば、1台ずつドライブを動的プールに追加して、プロビジョニングの柔軟性とコスト削減を実現できます。 

次の考慮事項は、動的プールに適用されます。

• 動的プールが作成されると、そのRAIDタイプまたはストライプ幅は変更できません。ただし、異なるドライブ タイプを使用してプールを拡張する場合は、追加されたドライブに、異なるストライプ幅を指定することができます。
• プール内で構成されているストレージ リソースとプール自体を削除することなく、動的プールを縮小したり、プールのストレージ特性を変更したりすることはできません。ただし、ドライブを追加してプールを拡張することはできます。
• 動的プールをプロビジョニングするとき、同じドライブ タイプで、容量が異なるフラッシュ ドライブを混在させることができます。ただし、これを行うと、大容量のドライブの容量のうち、一部の容量が使用されない可能性があります。これは、プール内の各容量のドライブ数に依存します。動的プールの未使用の容量は、将来のプールの拡張中に使用可能になる可能性があります。 

従来のプール

OEバージョン4.1.x以前を実行しているUnityVSAモデル、ハイブリッド モデル、Unityオール フラッシュ モデルで作成されたプールは、従来のプールです。OEバージョン4.2.x以降を実行しているUnityオール フラッシュ モデルの場合、Unisphere CLIまたはREST APIを使用して従来のプールを作成できますが、Unisphere UIを使用して作成することはできません。

従来のプールには、同種のプールと異種のプールがあります。同種プール内のすべてのドライブは、同じドライブ タイプ(SASドライブ、SASフラッシュ2ドライブなど)である。異種混在プール内のドライブには、NL-SAS、SAS、SASフラッシュ2ドライブの混在など、さまざまなドライブ タイプが混在しています。従来のプールは、オールフラッシュまたはハイブリッドにすることもできます。ハイブリッド プールには、フラッシュ ドライブと非フラッシュ ドライブが混在しています。サポートされているすべてのドライブ タイプをハイブリッド プールに含めることができます。ただし、SASフラッシュ4ドライブはオールフラッシュ プールに含める必要があります。

物理導入では、従来のプール内のストレージはRAIDグループ ユニットで管理されます。ここで、次のようになります。

• ドライブは1つのRAIDグループで消費されます。
• RAIDグループは、最大16台のドライブに制限されており、同じタイプのドライブで構成されます。
• 各階層は、1つのRAIDタイプをサポートします。

従来のプールのストレージはRAIDグループ単位で管理されるため、プールに容量を追加するには、RAIDグループ単位でドライブを追加する必要があります。たとえば、RAID 5 (4+1)を使用してプールにドライブを追加するには、少なくとも5台のドライブをプールに追加する必要があります。ドライブ容量が増加すると、プールに追加できるストレージの最小量とそのストレージのコストはますます大きくなります。

従来のプールには、次の考慮事項が適用されます。

• 従来のプールに階層が作成されると、階層内の既存ドライブのRAIDタイプまたはストライプ幅を変更することはできません。ただし、従来のプール内の階層を拡張する場合は、新しく追加されたドライブに別のストライプ幅を指定できます。従来のプールに新しい階層を追加する場合は、新しく追加するドライブに異なるRAIDタイプ、ストライプ幅、またはその両方を指定できます。
• プール内で構成されているストレージ リソースとプール自体を削除することなく、従来のプールを縮小したり、そのストレージ特性を変更したりすることはできません。ただし、ドライブを追加してプールを拡張することはできます。

従来のプールでは、ストレージ システムは専用のホット スペアを使用して、障害または障害が発生したドライブを交換します。適切なドライブ テクノロジーとサイズを備えたシステム内の未使用ドライブを使用して、プール内の障害または障害が発生したドライブを交換できます。同じタイプとサイズのスペア ドライブが利用できない場合、システムは同じタイプのより大きなドライブを使用できます。スペア ドライブは専用のホット スペアであるため、プールのパフォーマンスを向上させたり、フラッシュ ドライブの摩耗を軽減したりするために使用することはできません。また、ドライブに障害が発生した場合は、スペア ドライブでドライブ全体を再構築する必要があります。したがって、コンテンツが再構築される単一ドライブのパフォーマンスによって制限されるため、再構築時間は非常に長くなる可能性があります。これはパフォーマンスに影響を与える可能性があります。また、再構築プロセス中に別のドライブ障害が発生する可能性が高くなり、データ ロスにつながる可能性があります。

documentation/unity-family/unity-p-pool-config