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

設計

寄稿者

Epic 対応 FlexPod のアーキテクチャは、 Epic 、 Cisco 、ネットアップのいずれの導入ガイドにも基づいており、 Epic をご利用のお客様のサポート経験も豊富であるため、このアーキテクチャは適応性が高く、小規模なデータセンターや大規模なデータセンター、一元化、分散、マルチテナントのいずれの場合でも、 Epic のベストプラクティスを適用します。

適切なストレージアーキテクチャは、合計 IOPS を使用した全体的なサイズによって決まります。パフォーマンスだけを重視するわけではなく、お客様の追加の要件に基づいて、ノード数を増やすこともできます。ネットアップの利点は、要件の変化に応じてクラスタを無停止で簡単にスケールアップできることです。また、ノードをクラスタから無停止で削除して、転用したり機器の更新時に利用したりすることもできます。

NetApp ONTAP ストレージアーキテクチャのメリットには、次のようなものがあります。

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

  • * Storage Efficiency 。 * 重複排除、 FlexClone 、インライン圧縮、インラインコンパクション、シンレプリケーションにより、必要な総容量を削減 シンプロビジョニング、およびアグリゲートの重複排除:FlexClone 機能を使用すると、バックアップおよびテスト環境の更新に対応するクローンをほぼ瞬時に作成できます。これらのクローンは、変更が行われた場合にのみストレージを消費します。

  • * OnCommand WFA ワークフローの機能により、 Epic フルコピーテスト環境のバックアップと更新が可能 * 。この解決策はアーキテクチャを簡易化し、ストレージ容量を削減しながら効率化を実現します。これらのアーキテクチャは、 Epic 対応のバックアップ解決策を考慮しており、ストレージ統合を活用して任意のバックアップ解決策と統合できます。

  • * DR シャドウ・データベース・サーバ * DR シャドウ・データベース・サーバは ' お客様のビジネス継続性戦略の一部です(ストレージの読み取り専用 [SRO] 機能をサポートするために使用され ' ストレージの読み取り / 書き込み [SRW] インスタンスとして構成される可能性があります)したがって、 3 つ目のストレージシステムの配置とサイジングは、ほとんどの場合、本番用データベースストレージシステムと同じです。

  • * データベースの整合性(多少の考慮事項が必要)。 * SnapMirror バックアップコピーがビジネス継続性に関連して使用されている場合は、『 Epic Business Continuity Technical Solutions Guide 』( Epic Business Continuity Technical Solutions Guide )を参照してください。SnapMirror テクノロジの使用方法については、を参照してください "TR-3446 :『非同期 SnapMirror ベストプラクティスガイド』"

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

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

ストレージアーキテクチャ

次の図は 6 ノードアーキテクチャを示しています。これは Epic 環境で一般に導入されているアーキテクチャです。また、 4 ノードまたは 12 ノードの導入もありますが、これらのアーキテクチャは単に設計の基準となる点です。でワークロードを検証する必要があります "SPM" ディスク数とコントローラ利用率のサイジングツールAFF アレイにはすべての Epic 本番環境が導入されています。Epic ストレージレイアウトの要件については、 Epic All Flash Reference Architecture Strategy Handbook を参照してください。

注記 ネットアップの Epic チームと協力して、すべての設計を検証します。Epic では、ネットアップのサイジング手法を使用して、 Epic 環境で使用するネットアップストレージシステムのサイズを適切に設定する必要があります。詳細については、を参照してください "TR-3930i :『 NetApp Sizing Guidelines for Epic 』"。このドキュメントを参照するには、 NetApp Field Portal へのアクセスが必要です。

6 ノードのアーキテクチャには、本番用に 4 つのノードがあり、 DR 用に 2 つのノードが含まれています。このアーキテクチャでは、 4 ノードの運用が可能な Epic オールフラッシュリファレンスアーキテクチャ戦略ハンドブックに、 Clarity の Epic Report ワークロードを分離できると記載されています。

ノードを 6 つ配置することには、次の主な利点があります。

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

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

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

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

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

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

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

ストレージの設計とレイアウト

Epic の HA と冗長性の要件を満たすための最初のステップは、 Epic ソフトウェア環境に特化したストレージレイアウトの設計です。たとえば、ディスクプール 1 をディスクプール 2 から専用の高性能ストレージに分離します。各ディスクプールのワークロードについては、『 Epic All-Flash Reference Architecture Strategy 』を参照してください。

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

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

次の図は、 6 ノードアーキテクチャのストレージレイアウトを示しています。各ストレージシステムは、完全に冗長な HA ペアのシングルノードです。このレイアウトにより、各コントローラでの利用率とストレージ効率が最大限に高まります。

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

ストレージノードの構成

  • 高可用性 *

HA ペアのノードで構成されているストレージシステムは、ノード障害の影響を軽減し、ストレージシステムの無停止アップグレードを可能にします。複数のパスを使用してノードに接続されたディスクシェルフは、シングルパス障害から保護することでストレージの耐障害性を高め、ノードフェイルオーバー時のパフォーマンスの一貫性を向上させます。

  • ハードウェアアシストフェイルオーバー *

ハードウェアアシストフェイルオーバーでは、 1 つのノードのリモート LAN モジュールまたはサービスプロセッサモジュールがハートビートタイムアウトトリガーよりも早くノード障害をパートナーに通知できるようにすることで、ストレージノードのフェイルオーバー時間を最小限に抑えます。これにより、フェイルオーバー前の経過時間を短縮できます。ストレージが仮想化されている場合、フェイルオーバー中にコントローラの ID を移動する必要がないため、フェイルオーバーにかかる時間が短縮されます。ソフトウェアディスクの所有権のみが変更されます。

  • ネットアップのサポートツールとサービス *

ネットアップでは、包括的なサポートツールとサービスを提供しています。ネットアップストレージシステムでは、ハードウェア障害やシステムの構成ミスが発生した場合にホームコールを行うために、 NetApp AutoSupport ツールを有効にして設定する必要があります。ミッションクリティカルな環境については、ネットアップでは SupportEdge Premium パッケージも推奨しています。このパッケージを使用すると、運用に関する専門知識の習得、サポート時間の延長、パーツ交換の所要時間の短縮を実現できます。

  • AFF A300 および AFF A700 コントローラでオールフラッシュに最適化されたパーソナリティ *

AFF 解決策が正しく機能するには、完全にフラッシュで最適化された FAS80x0 システムの HA ペアの両方のノードで、環境変数「 bootarg.init.flash_optimized` 」を「 true 」に設定する必要があります。オールフラッシュで最適化されたプラットフォームでは、 SSD のみがサポートされます。

ボリューム構成

  • Snapshot コピー *

本番環境のデータベースにストレージを提供するボリュームに対しては、夜間ボリュームレベルの Snapshot スケジュールを設定する必要があります。ボリュームレベルの Snapshot コピーは、開発、テスト、ステージングなどの非本番環境で使用する本番環境データベースのクローニングのソースとしても使用できます。ネットアップでは、 Epic を使用した OnCommand WFA ワークフローを開発し、本番環境のデータベースのバックアップやテスト環境の更新を自動化しています。これらのワークフローは、アプリケーションと整合性のある Snapshot コピー用にデータベースをフリーズして解凍します。本番環境のバックアップコピーは、サーバのサポート、リリース、およびリリースの検証をテストするために自動的に提示されます。これらのワークフローは、バックアップのストリーミングと整合性チェックにも使用できます。

スナップショットコピーを使用して、 Epic の本番データベースの復元操作をサポートできます。

SnapMirror を使用すると、本番環境とは別のストレージシステムに Snapshot コピーを保持できます。

SAN ボリュームの場合は、各ボリュームでデフォルトの Snapshot ポリシーを無効にします。作成される Snapshot コピーは、通常、バックアップアプリケーションまたは OnCommand の WFA ワークフローによって管理されます。ディスク利用率を最大限に高めるために、すべての効率化設定を有効にすることを推奨します。

  • ボリュームアフィニティ *

ONTAP は、同時処理をサポートするために、起動時に使用可能なハードウェアを評価し、アグリゲートとボリュームをアフィニティと呼ばれる別のクラスに分割します。一般に、アフィニティに属するボリュームは、他のアフィニティにあるボリュームと並行して処理できます。対照的に、同じアフィニティ内にある 2 つのボリュームでは、ノードの CPU でスケジューリング時間(シリアル処理)を待つ必要があります。

AFF A300 および AFF A700 には、アグリゲートアフィニティが 1 つと、ノードごとにボリュームアフィニティが 4 つあります。ノードの利用率を最大限にし、ボリュームアフィニティを使用するには、ストレージレイアウトをノードごとに 1 つのアグリゲートにし、ノードごとに少なくとも 4 つのボリュームにする必要があります。通常、 Epic データベースには 8 つのボリュームまたは LUN が使用されます。

LUN の設定

『 Epic Database Storage Layout Recommendations 』ドキュメントには、各データベースの LUN のサイズと数が詳しく記載されています。Epic のサポート状況を確認し、 LUN や LUN のサイズの最終決定を行うことが重要で、多少の調整が必要な場合があります。

LUN 自体のサイズはストレージにコストをかけずに済むため、 LUN のサイズを大きくしておくことを推奨します。運用を容易にするため、 LUN の数と初期サイズは、 3 年後に想定される要件を大きく超えても大きくなることを確認してください。LUN の拡張は、拡張時に LUN を追加する場合よりも管理しやすくなります。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 が必要になります。

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