日本語は機械翻訳による参考訳です。内容に矛盾や不一致があった場合には、英語の内容が優先されます。

Epic に対応したネットアップストレージリファレンスアーキテクチャ

寄稿者

データベースの全体的なサイズと合計 IOPS によって、適切なストレージアーキテクチャを決定できます。パフォーマンスだけを重視するわけではなく、お客様の追加の要件に基づいて、より大きなノード数を使用する場合もあります。

Epic ソフトウェア環境のストレージ要件を考慮すると、ネットアップは環境の規模に応じて 3 種類のリファレンスアーキテクチャを用意しています。Epic では、ネットアップのサイジング手法を使用して、 Epic 環境で使用するネットアップストレージシステムのサイズを適切に設定する必要があります。パフォーマンス要件とサイジングに関する定量的なガイダンスについては、ネットアップを参照してください "TR-3930i :『 NetApp Sizing Guidelines for Epic 』"。このドキュメントを参照するには、 NetApp Field Portal へのアクセスが必要です。

ここに示すアーキテクチャは、設計の出発点です。ディスク数とコントローラ利用率について、 SPM ツールでワークロードを検証する必要があります。ネットアップの Epic チームと協力して、すべての設計を検証します。

オールフラッシュアレイに導入された Epic 本番環境本レポートでは、回転式ディスクに必要なディスクプールを、オールフラッシュアレイの 3 つのディスクプールに統合しました。このセクションを読む前に、 Epic ストレージレイアウトの要件について Epic オールフラッシュリファレンスアーキテクチャ戦略ハンドブックを確認してください。

3 つのストレージリファレンスアーキテクチャは次のとおりです。

  • * 小規模 * 本番環境に 2 ノード、 DR 環境に 2 ノード構成の 4 ノードアーキテクチャ(グローバルリファレンスが 5 万未満)

  • * 中規模 * 6 ノードアーキテクチャで、本番環境に 4 ノード、 DR 環境に 2 ノード( 5M を超えるグローバルリファレンス)

  • * 大規模 * 本番環境に 6 ~ 10 ノードの 12 以上のノードアーキテクチャ( 5M-10M グローバルリファレンス)

注記 グローバルリファレンス = (読み取り IOPS + (書き込み処理数 / 80 秒書き込みバースト / 45 )) * 225これらの数値は、お客様向けの Epic Hardware Configuration Guide に記載されています。

ストレージレイアウトと LUN 構成

Epic の高可用性( HA_/ 冗長性の要件)を満たすための最初のステップは、 Epic ソフトウェア環境に特化したストレージレイアウトの設計です。設計上の考慮事項には、ディスクプール 1 をディスクプール 2 から専用のハイパフォーマンスストレージに分離することが含まれている必要があります。各ディスクプールのワークロードについては、『 Epic All-Flash Reference Architecture Strategy 』を参照してください。

各ディスクプールを別々のノードに配置すると、 Epic の本番ワークロードと非本番ワークロードの分離に必要なフォールトドメインが作成されます。ノードごとに 1 つのアグリゲートを使用すると、ディスク利用率とアグリゲートアフィニティが最大化され、パフォーマンスが向上しますまた、アグリゲートレベルの重複排除により、ストレージ効率も最大化されます。

Epic を使用すると非本番環境のニーズに合わせてストレージリソースを共有できるため、 Clarity サーバと本番環境サービスに必要な仮想デスクトップインフラ( VDI )、 CIFS 、その他のエンタープライズ機能の両方に対応できるストレージシステムが多くなります。

Epic Database Storage Layout Recommendations ドキュメントには、各データベースの LUN のサイズと数に関する推奨事項が記載されています。これらの推奨事項は、環境に応じて調整する必要があります。Epic のサポートでこれらの推奨事項を確認し、 LUN と LUN のサイズの決定を行うことが重要です。

注記

LUN 自体のサイズはストレージコストを含まないため、サイズの大きい LUN から開始することを推奨します。運用を容易にするため、 LUN の数と初期サイズは、 3 年後に想定される要件を大きく超えても大きくなることを確認してください。LUN の拡張は、拡張時に LUN を追加する場合よりも管理しやすくなります。シンプロビジョニングされた LUN とボリュームでは、ストレージの使用済みスペースがアグリゲートに表示されます。

EPIC を使用するには、データベース、ジャーナル、アプリケーション、またはシステムのストレージを、 FC 経由でデータベースサーバに LUN として提供する必要があります。

Epic の本番用と Clarity には、ボリュームごとに 1 つの LUN を使用します。大規模な導入では、 Epic データベースに 24 ~ 32 個の LUN を推奨しています。使用する LUN の数を決定する要因は次のとおりです。

  • 3 年後の Epic DB の全体的なサイズ。DB のサイズが大きい場合は、そのオペレーティングシステム( OS )用の LUN の最大サイズを確認し、拡張可能な LUN が十分にあることを確認してください。たとえば、 60TB の Epic データベースを必要とし、 OS LUN の最大容量が 4TB の場合、拡張性とヘッドルームを確保するには、 24~32 個の LUN が必要です。

小規模、中規模、大規模のいずれのアーキテクチャであるかに関係なく、次の点に注意してください。

  • ONTAP では、システムを停止することなく簡単にスケールアップおよびスケールアウトできます。ONTAP のノンストップオペレーションを使用して、ディスクとノードをアップグレード、追加、または削除できます。システムを停止することなく、 4 ノード構成から始めて 6 ノード構成に移行したり、大容量のコントローラにアップグレードしたりできます。

  • ネットアップの OnCommand Workflow Automation ワークフローでは、 Epic のフルコピーテスト環境のバックアップと更新が可能です。この解決策は、アーキテクチャを簡易化し、ストレージ容量を削減すると同時に効率化も実現します。

  • DR シャドウデータベースサーバは、お客様のビジネス継続性戦略の一部です( SRO 機能をサポートするために使用され、 SRW インスタンスとして設定される可能性があります)。したがって、 3 つ目のストレージシステムの配置とサイジングは、通常、本番用データベースストレージシステムの場合と同じです。

  • データベースの整合性を確保するにはいくつか考慮するビジネス継続性に関する NetApp SnapMirror バックアップコピーを使用している場合は、 Epic ドキュメント『 Business Continuity Technical Solutions Guide 』を参照してください。SnapMirror テクノロジの使用方法については、を参照してください "TR-3446 :『非同期 SnapMirror ベストプラクティスガイド』"

  • Epic の主要な設計目標は、本番環境と潜在的な Bully ワークロードを分離することです。ストレージプールは、ワークロードのパフォーマンスを分離して保護する必要がある障害ドメインです。ONTAP クラスタ内の各ノードはフォールトドメインであり、ストレージプールとみなすことができます。

ONTAP ファミリーのすべてのプラットフォームで、 Epic ワークロードに対応した多数の機能セットを実行できます。

小規模構成: 5 万未満のグローバルリファレンス(最大 2 万 2 、 000 IOPS )に対応する 4 ノードリファレンスアーキテクチャ

小規模リファレンスアーキテクチャは 4 ノードアーキテクチャで、本番環境に 2 つのノード、 DR に 2 つのノードを配置し、 5M 以下のグローバルリファレンスで構成されています。このアーキテクチャは、グローバルリファレンスが 5 万未満のお客様に使用できます。このサイズでは、レポートと Clarity を分離する必要はありません。

ネットアップ独自のマルチプロトコルサポート、 QoS 、障害ドメインを同じクラスタ内に作成できるため、ディスクプール 1 とディスクプール 2 のすべての本番ワークロードを単一の HA ペア上で実行し、ネットアップのベストプラクティスと Epic High Comfort の評価要件をすべて満たすことができます。ディスクプール 1 はすべてノード 1 で実行され、ディスクプール 2 はすべてプール 2 で実行されます。

ONTAP を使用して同じクラスタ内のワークロードを分離し、 ONTAP マルチプロトコルをサポートすることで、本番環境の Epic ワークロード( Production 、 Report 、 Clarity 、 VMware 、 Citrix 、 CIFS や Epic 関連のワークロードなど)は、単一クラスタの単一の HA ペアで実行できます。この機能により、 Epic のすべての要件( Epic All Flash Reference Architecture Strategy Handbook に記載)やネットアップのすべてのベストプラクティスに対応できるようになります。基本的に、次の図に示すように、 pool1 はノード pro-01 で、 pool2 は prod -02 で実行されます。NAS 1 のワークロードは、ネットアップのマルチプロトコル NAS および SAN 機能を備えたノード 2 に配置できます。

ディザスタリカバリのために、 Epic DR pool 3 が HA ペアの 2 つのノードに分割されています。EPIC DR はノード DR-01 で実行され、 DR サービスは DR-02 で実行されます。

ワークロードに対して、 NetApp SnapMirror または SnapVault レプリケーションを必要に応じて設定できます。

エラー:グラフィックイメージがありません

ストレージの設計とレイアウトの観点から見た場合、次の図は、本番環境のデータベースのストレージレイアウトの概要と、 Epic ワークロードを構成するその他の構成要素を示しています。

エラー:グラフィックイメージがありません

中規模構成: 5 万件を超えるグローバルリファレンスに対応した 6 ノードリファレンスアーキテクチャ(合計 2 、 000 万 ~5 、 000 IOPS )

中規模リファレンスアーキテクチャは本番環境に 4 ノード、 DR 環境に 2 ノードの構成で、 5M-10M のグローバルリファレンスを持つ 6 ノードアーキテクチャです。

このサイズの『オールフラッシュリファレンスアーキテクチャ戦略ハンドブック』では、 Epic Report のワークロードを Clarity から分離する必要があり、本番環境に少なくとも 4 つのノードが必要であると記載しています。

6 ノードアーキテクチャは、 Epic 環境で最も一般的に導入されているアーキテクチャです。500 万を超えるグローバルリファレンスを持つお客様は、 Report と Clarity を別々のフォールトドメインに配置する必要があります。Epic オールフラッシュリファレンスアーキテクチャ戦略ハンドブックを参照

グローバルリファレンスが 5 、 000 、 000 個未満のお客様は、次の主なメリットを得るために、 4 つのノードではなく 6 つのノードを使用することを選択できます。

  • バックアップアーカイブプロセスを本番環境からオフロード

  • すべてのテスト環境を本番環境からオフロード

本番環境はノード pro-01 で実行レポートは本番環境の最新の Epic ミラーコピーである node-02 で実行されます。サポート、リリース、リリース検証などのテスト環境は、 Epic 本番、 Report 、 DR のいずれかからクローニングできます。次の図は、本番環境からフルコピーテスト環境用に作成されたクローンを示しています。

2 つ目の HA ペアは、本番用サービスのストレージ要件に使用されます。これらのワークロードには、 Clarity データベースサーバ( SQL または Oracle )、 VMware 、ハイパースペース、 CIFS 用のストレージが含まれます。このアーキテクチャでは、 Epic 対応ではないワークロードをノード 3 とノード 4 に追加したり、可能であれば同じクラスタ内の別の HA ペアに追加したりすることができます。

SnapMirror テクノロジは、本番環境のデータベースを 2 つ目の HA ペアにストレージレベルでレプリケートするために使用されます。SnapMirror バックアップコピーを使用して、サポート、リリース、リリース検証などの非本番環境用の NetApp FlexClone ボリュームを 2 つ目のストレージシステムに作成できます。本番データベースのストレージ・レベルのレプリカは ' お客様の DR 戦略の導入にも対応できます

ストレージ効率を高めるために、 Report NetApp Snapshot コピーバックアップからフルテストクローンを作成し、ノード 2 で直接実行することもできます。この設計では、 SnapMirror デスティネーションのコピーをディスクに保存する必要はありません。

エラー:グラフィックイメージがありません

次の図は、 6 ノードアーキテクチャのストレージレイアウトを示しています。

エラー:グラフィックイメージがありません

大規模な設定: 1 、 000 万を超えるグローバルリファレンス( 5 万以上の IOPS )に対応するリファレンスアーキテクチャ

大規模なアーキテクチャは通常 12 ノード以上のノードアーキテクチャで、本番用ノードは 6 ~ 10 ノードで構成されており、これには 10 万を超えるグローバルリファレンスが含まれています。大規模な Epic 環境では、次の図に示すように、 Epic Production 、 Epic Report 、 Clarity を専用の HA ペアに配置し、ノード間でストレージを均等に分散させることができます。

大規模なお客様には 2 つのオプションがあります

  • 6 ノードアーキテクチャを維持し、 AFF A700 コントローラを使用する。

  • AFF A300 の専用 HA ペアで、 Epic 本番、 Report 、 DR を実行

コントローラ利用率を比較するには、 SPM を使用する必要があります。また、コントローラを選択する際にはラックスペースと電源も考慮してください。

エラー:グラフィックイメージがありません

次の図に、大規模なリファレンスアーキテクチャのストレージレイアウトを示します。

エラー:グラフィックイメージがありません