Epicアーキテクチャ
変更を提案
PDF
このセクションでは、Epicソフトウェア環境と、ストレージを必要とする主なコンポーネントについて説明します。ストレージ設計の指針となる主な考慮事項が記載されています。
ウィスコンシン州ヴェローナに本社を置くEPICは、中規模から大規模の医療グループ、病院、統合医療機関向けのソフトウェアを製造しています。顧客には、コミュニティ病院、学術施設、子供の組織、セーフティネットプロバイダー、マルチホスピタルシステムも含まれます。Epicに統合されたソフトウェアは、臨床、アクセス、収益の各機能にまたがっており、家庭でも利用できます。
Epic ソフトウェアでサポートされる幅広い機能については、本ドキュメントでは説明していません。ただし、ストレージシステムの観点からは、すべてのEpicソフトウェアが導入環境ごとに1つの患者中心のデータベースを共有します。エピックはInterSystems Cach é データベースから新しいInterSystems Irisデータベースに移行しています。CacheとIrisのストレージ要件は同じであるため、このドキュメントの残りの部分ではデータベースをIrisと呼びます。IrisはAIXおよびLinuxオペレーティングシステムで利用可能である。
インターシステムズアイリス
InterSystems Irisは、Epicアプリケーションで使用されるデータベースです。このデータベースでは、データサーバは永続的に保存されるデータのアクセスポイントです。アプリケーションサーバは、データベースクエリを管理し、データサーバにデータ要求を行います。ほとんどのEpicソフトウェア環境では、単一のデータベースサーバで対称型マルチプロセッサ（SMP）アーキテクチャを使用すれば、Epicアプリケーションのデータベース要求に対応できます。大規模な展開では、InterSystemsのEnterprise Cach é Protocol（ECP）を使用して分散モデルをサポートできます。
フェイルオーバー対応のクラスタハードウェアを使用すると、スタンバイデータサーバはプライマリデータサーバと同じストレージにアクセスできます。また、スタンバイデータサーバがハードウェア障害時に処理を引き継ぐこともできます。
InterSystemsは、データレプリケーション、ディザスタリカバリ、高可用性（HA）の要件を満たすテクノロジも提供します。InterSystemsのレプリケーション技術は、プライマリデータサーバーから1つ以上のセカンダリデータサーバーに、Irisデータベースを同期または非同期で複製するために使用されます。NetApp SnapMirrorは、WebBLOBストレージのレプリケート、またはバックアップとディザスタリカバリに使用されます。
更新されたIrisデータベースには多くの利点があります。
-
拡張性が向上し、複数のEpicインスタンスを持つ大規模な組織でも、1つの大規模なインスタンスに統合できます。
-
新しいプラットフォームライセンスに料金を支払うことなく、AIXとRed Hat Enterprise Linux（RHEL）を切り替えることができる、ライセンスの休日です。
Cach é のデータベースサーバとストレージの使用状況
-
本番環境 Epicソフトウェア環境では、1つの患者中心のデータベースが導入されます。Epicのハードウェア要件では、プライマリ読み取り/書き込みIrisデータサーバをホストする物理サーバを本番データベースサーバと呼びます。このサーバでは、プライマリデータベースインスタンスに属するファイルを格納するために、ハイパフォーマンスなオールフラッシュストレージが必要です。高可用性を実現するために、Epicでは、同じファイルにアクセスできるフェールオーバーデータベースサーバの使用をサポートしています。IrisはEpic Mirrorを使用して読み取り専用レポートに複製し、ディザスタリカバリを行い、読み取り専用コピーをサポートしています。ビジネス継続性のために'各タイプのデータベース・サーバを読み取り/書き込みモードに切り替えることができます
-
*レポート*レポート・ミラー・データベース・サーバは'本番データへの読み取り専用アクセスを提供します本番Irisデータサーバーのバックアップミラーとして構成されたIrisデータサーバーをホストします。レポート用データベースサーバのストレージ容量要件は、本番用データベースサーバのストレージ容量要件と同じです。書き込みパフォーマンスのレポートは本番環境と同じですが、読み取りワークロードの特性やサイズが異なります。
-
*読み取り専用*このデータベースサーバーはオプションで、下の図には示されていません。また、ミラーデータベースサーバを導入して、Epicが読み取り専用モードで本番環境のコピーにアクセスできる読み取り専用機能をサポートすることもできます。このタイプのデータベースサーバは、ビジネス継続性のために読み取り/書き込みモードに切り替えることができます。
-
*ディザスタリカバリ*ビジネス継続性とディザスタリカバリの目標を達成するために、ディザスタリカバリミラーデータベースサーバは、通常、本番ミラーデータベースサーバやレポートミラーデータベースサーバとは地理的に離れたサイトに配置されます。ディザスタリカバリミラーデータベースサーバーは、本番Irisデータサーバーのバックアップミラーとして構成されたIrisデータサーバーもホストします。本番サイトが長時間使用できなくなった場合、このバックアップ・ミラー・データベース・サーバは、ミラーの読み取り/書き込みインスタンス（SRW）として機能するように構成できます。バックアップミラーデータベースサーバのファイルストレージ要件は、本番データベースサーバのファイルストレージ要件と同じです。一方、バックアップミラーデータベースのストレージは、ビジネス継続性の観点からは本番用ストレージと同じサイズになります。
-
*テスト*医療機関は多くの場合、開発、テスト、ステージング環境を導入しています。これらの環境のための追加のIrisデータサーバーにもストレージが必要であり、同じストレージシステムで対応できます。Epicには、共有ストレージシステムから追加ストレージを提供するための固有の要件と制約があります。これらの固有の要件には、本ドキュメントのベストプラクティスに従って一般的に対処しています。
Epicソフトウェア環境には、Iris ODBデータサーバに加えて、次のような他のコンポーネントが含まれています（下図を参照）。
-
EpicのClarityビジネスレポートツールのバックエンドとして使用するOracleまたはMicrosoft SQL Serverデータベースサーバ
|
Clarityは、レポートIrisデータベースから毎日抽出されたデータを報告するために使用されます。 |
-
WebBLOBサーバ（SMB）
-
多目的データベースサーバ
-
多目的仮想マシン（VM）
-
クライアントアクセスヨウノハイパースペース
これらすべての複数のワークロード、プール、NASプロトコル、SANプロトコルのストレージ要件は、単一のONTAPクラスタで統合してホストすることができます。この統合により、医療機関は、EpicとEpic以外のすべてのワークロードに対して単一のデータ管理戦略を策定できます。
運用データベースワークロード
各Epicデータベースサーバは、次の種類のファイルに対してI/Oを実行します。
-
データベースファイル
-
ジャーナルファイル
-
アプリケーションファイル
個 々 のデータベースサーバのワークロードは、Epicソフトウェア環境でのサーバの役割によって異なります。たとえば、本番環境のデータベースファイルには、100%ランダムI/O要求で構成される最も要件の厳しいワークロードが一般的に発生します。一般に、ミラーデータベースのワークロードの負荷は低く、読み取り要求も少なくなります。ジャーナルファイルのワークロードは、主にシーケンシャルです。
Epicは、ストレージパフォーマンスのベンチマークとお客様のワークロードのためのワークロードモデルを維持しています。Epicワークロードモデル、ベンチマーク結果、NetAppサイジングツールを使用してEpic環境のストレージを正しくサイジングするためのガイダンスの詳細については、（NetAppへのログインが必要）を参照してください "TR-3930i ：『 NetApp Sizing Guidelines for Epic 』"。
また、Epicは、I/O予測とストレージ容量要件を含むカスタマイズされたハードウェア構成ガイドを各顧客に提供します。最終的なストレージ要件には、開発環境、テスト環境、ステージング環境、および統合可能なその他の付随するワークロードが含まれる場合があります。ハードウェア構成ガイドを使用して、ストレージの総要件をNetAppに伝えることができます。このガイドには、Epic環境のサイジングに必要なすべてのデータが記載されています。
導入フェーズでは、Epicから『Database Storage Layout Guide』が提供されます。このガイドでは、高度なストレージ設計に使用できるLUNレベルの詳細情報を提供します。『データベースストレージレイアウトガイド』はストレージに関する一般的な推奨事項であり、NetAppに固有のものではありません。このガイドを使用して、NetAppに最適なストレージレイアウトを判断してください。