Epic LUNおよびボリューム構成
変更を提案
PDF
各データベースのLUNのサイズと数については、Epic Database Storage Layout Recommendationsを参照してください。
Epic DBAとEpicのサポートを受けて本ドキュメントを確認し、必要に応じてLUNの数とLUNサイズを決定することが重要です。これらのストレージの推奨事項は、HBAのキュー深度、ストレージパフォーマンス、運用のしやすさ、および拡張のしやすさにとって重要です。
サーバOSのキュー深度を考慮する場合は、データベースに少なくとも8つのLUN（ボリュームごとに1つのLUN）を使用します。ONTAPクラスタのノードの数だけLUNの数を増やします。たとえば、4ノード（2つのHAペア）クラスタを使用している場合は、LUNを4つ追加します。大規模な環境では、より多くのLUNが必要になる場合があります。同じ数のボリューム（合計8個、ストレージノードに分散）を使用し、クラスタノードおよびボリューム全体でLUNを2の倍数で追加します。このアプローチにより、Epic環境を簡単に拡張できます。
例1：2ノードのONTAPクラスタ
2ノード、1 HAペア8ボリューム、ノードあたり4ボリューム8 LUN、ボリュームあたり1 LUN追加のLUNを2つ追加します（volume01のNode01に1つ、volume02のNode02に1つ）。
例2：4ノードのONTAPクラスタ
4ノード、2 HAペア8ボリューム、ノードあたり2ボリュームLUN、ボリュームあたり1つ追加のLUNを4つ追加します。1つはvolume01のNode01に、もう1つはvolume02のNode02に、もう1つはvolume03のnode03に、もう1つはvolume04のnode04にです。
Epic ODBやClarityなどのワークロードのパフォーマンスを最大化するには、各レイアウトがNetAppストレージに最適です。8個のボリュームを使用することで、書き込みIOがコントローラ間で均等に分散され、CPU利用率が最大化されます。レプリケーションとバックアップでは、運用を簡易化するために、ボリューム数を8個に制限することを推奨します。
スケーリングオプション
サーバでストレージの追加が必要な場合は、ボリュームを含むLUNを拡張するのが最も簡単な方法です。2つ目の方法は、一度に2の倍数（各ノードのボリュームごとに1つ）でボリュームグループにLUNを追加する方法です。
例
ボリュームと8 LUNのレイアウト
|
4ノードまたは8個以上のLUNが必要な大規模な環境では、EpicアライアンスチームにLUNの設計を確認してください。チームはEpic @ NetApp .comで連絡することができます。 |
ベストプラクティス
-
8個のボリュームで8個のLUNを使用して開始し、クラスタのすべてのノードで一度に2個のLUNを追加します。
-
HAペア間でワークロードを分散して、パフォーマンスと効率を最大化します。
-
3年間の拡張が想定されるサイズでLUNを作成します。（LUNの最大サイズについては、を参照して"ONTAPのドキュメント"ください）。
-
シンプロビジョニングされたボリュームとLUNを使用する。
-
少なくとも8つのDB LUN、2つのジャーナルLUN、2つのアプリケーションLUNを使用します。この構成により、ストレージパフォーマンスとOSのキュー深度を最大限に高めることができます。容量やその他の理由で必要に応じて、より多くのものを使用できます。
-
ボリュームグループにLUNを追加する必要がある場合は、一度に8個のLUNを追加します。
-
ボリュームとLUNのグループを一緒にバックアップするには、整合グループ（CG）が必要です。
-
GenioまたはI/Oのパフォーマンス中はQoSを使用しないでください。
-
GenioまたはClarityのテスト後、NetAppでは、本番データをロードする前にストレージを削除して再プロビジョニングすることを推奨しています。
-
LUNでenabledが設定されていることが重要です
-space-allocation。そうでない場合、LUN上で削除されたデータはONTAPで認識されず、容量の問題が発生する可能性があります。詳細については、『Epic Storage Configuration Quick Reference Guide』を参照してください。