#ECP

これは InterSystems FAQ サイトの記事です。
こちらのトピックでは、ミラー環境でECPを行う場合の設定方法と注意すべき点について、ご案内します。

【設定方法】

手順は以下になります。

(1) 両方のフェイルオーバーメンバおよび任意の DR 非同期メンバで、ECPを有効にします

(2) ECP アプリケーションサーバ（ECPクライアント）で、ECPの設定を行います

(3) ECP アプリケーションサーバ（ECPクライアント）で、リモートデータベースの作成を行います

(4) 動作確認＆リダイレクトのテストを行います

今回作成するECP構成は、ドキュメントにある以下のイメージの赤丸のインスタンスによる構成になります。

(1) 両方のフェイルオーバーメンバおよび

インターシステムズは、以下2点の修正を行いました。

.

障害1: ECP アプリケーションサーバがハングする

以下の CPU かつ 以下のバージョンで発生します。
    対象バージョン: 2022.1.2, 2022.1.3
    対象CPU: ARM, IBM Power プロセッサ
この問題は修正ID DP-423661 で解決します。この修正は、今後のすべてのバージョンに含まれる予定です。 

.

障害2: 非常に稀な状況において デジャーナルがハングする

デジャーナルとはジャーナルをリストアすることで、例えば、ミラーリングのフェイルオーバーやDR非同期メンバで常時実行されています。また障害復旧に際しジャーナルをリストアする作業も対象になります。

本障害は以下のバージョンで発生します。
    対象バージョン: 2020.4, 2021.x, 2022.x, 2023.1
この問題は修正ID DP-423505 で解決します。この修正は、今後のすべてのバージョンに含まれる予定です。また 2023.1.1 には既に含まれています。

.

これら2点の修正を入手いただけるよう、公開済みの 2022.1.3 の更新版を公開いたしました。バージョン番号は以下の通りです。

    過去版:  2022.1.3.668.0
    更新版:  2022.1.3.670.1

お客

インターシステムズは、まれに Enterprise Cache Protocol (ECP) クライアントが不安定になることがある不具合を修正しました。

この不具合は、以下の製品およびそれらをベースとしたインターシステムズの製品に存在します。

影響を受けるバージョン: 2022.1.x, 2022.2, 2022.3

InterSystems IRIS®

InterSystems IRIS for Health™

HealthShare® Health Connect

影響を受けるバージョン: 2022.2 (ECPを導入しているお客様のみ)

InterSystems HealthShare®

この問題は、ECPクライアントシステムでのみ発生する可能性があります。この問題が発生すると、プロセスで <SYSTEM> または <DATABASE> エラーが発生することがあります。エラー後、ECPクライアントが不安定になり、場合によってはインスタンスがハングアップすることがあります。データへの影響はなく、ECP データサーバーも影響を受けません。

不安定な状態を解消するには、ECP クライアントインスタンスを再起動する必要があります

IRIS、IRIS for Health、またはHealth Connectのインスタンスに影響がある場合、近日中にリリースされるバージ

開発者の皆さん、こんにちは！

コミュニティウェビナーの再開をお知らせします！
​​​​​

今回は、@Ron.Sweeney1582による「Scaling InterSystems FHIR Server on Amazon Web Services with ECP」というウェビナーに皆さんをご招待します。

このウェビナーでは、Amazon Web Services 上の InterSystems FHIR Server を Enterprise Cache Protocol (ECP) を使ってスケールアウトする技術的な詳細、デモ、ベンチマークを紹介します。

⏱ 日時: 8月18日（木）午前8時（東部標準時）、午後9時（日本標準時）
👨‍🏫 スピーカー: @sween, Integration Required社 フルスタックアーキテクト

対象バージョン
  2020.1.0以降のInterSystems IRISおよびInterSystems IRIS for Healthのすべてのメジャー・リリースおよびメンテナンス・バージョン
  
対象プラットフォーム
    全て

発生する問題
  分散型キャッシュ・クラスタ(ECP 構成) でアプリケーションのロック保証に違反し、アプリケーションの整合性に問題が生じる可能性があります。

問題の詳細
  この問題は、データサーバの再起動またはフェイルオーバー後に、アプリケーションサーバがECPリカバリを正常に実行した場合にのみ発生します。
以下のようなケースです。

• 再起動時またはフェイルオーバー時に、アプリケーションサーバ上で実行されているプロセスがデータサーバ上のデータベースに対して合計255個以上のロックを保持している場合、これらのロックの一部がデータサーバのロックテーブルに記録されないことがあります。    
• データサーバはクラスタ全体に分散するのロックを管理しているため、他のアプリケーションサーバ上のプロセスやデータサーバ自身が、アプリケーションサーバが保持するロックのいずれかと競合するロックを同時に取得する可能性があり、アプリケーションの整合性に問題が発生する可能性があります。

* ECPリカバリについては、こちらのドキュメントを参照してください。

* ロッ

先週、私たちはInterSystems IRIS Data Platformを発表しました。これは、トランザクション、分析、またはその両方に関係なく、あらゆるデータの取り組みに対応する新しい包括的なプラットフォームです。 CachéとEnsembleでお客様が慣れ親しんでいる多くの機能が取り込まれていますが、この記事では、プラットフォームの新機能の1つであるSQLシャーディングについてもう少し詳しく説明します。これはスケーラビリティに関する強力な新機能です。 

ちょうど4分41秒の時間がある方は、スケーラビリティに関するこちらの詳しい動画をご覧ください。 ヘッドホンがない方や聞き心地の良いナレーションが同僚の方の迷惑になると思う方は、どうぞ読み進めてください！ 

スケールアップとスケールアウト 

1日に何百万件という株取引を処理する場合でも、1日に数万人の患者を治療する場合でも、このような業務を支えているデータプラットフォームは、こういった大きなスケールに透過的に対処できなければなりません。 「透過的に」というのは、プラットフォームがスケーリングの面を請け負い、開発者やビジネスユーザーは処理量を気にすることなく、それぞれが専門とする業務とアプリケーションに専念することができるという意味です。 

長年にわたり、Cachéは垂直スケーラビリティをサポートしてきました。ハード

Cachéの優れた可用性とスケーリング機能の1つは、エンタープライズキャッシュプロトコル（ECP）です。 アプリケーション開発中に考慮することにより、ECPを使用した分散処理は、Cachéアプリケーションのスケールアウトアーキテクチャを可能にします。 アプリケーション処理は、アプリケーションを変更することなく、単一のアプリケーションサーバーから最大255台といった非常に高いレートにまで、アプリケーションサーバー処理能力を拡張できます。 

ECPは、私が関与していたTrakCareのデプロイメントで長年広く使用されていました。 10年前は、主要ベンダーの1つが提供する「大きな」x86サーバーは、合計で8つのコアしか備えていなかったかもしれません。 大規模なデプロイメントの場合、ECPは、高価な大型コンピュータを使う単一のエンタープライズサーバーではなく、コモディティサーバーでの処理をスケールアウトする方法でした。 コア数の多いエンタープライズサーバーでさえ制限があったため、ECPはそれらのサーバーへのデプロイメントのスケーリングにも使用されました。 

現在、ほとんどの新しいTrakCareのデプロイメントや主流ハードウェアへのアップグレードは、ECPでのスケーリングを必要としません。 現行の2ソケットx86プロダクションサーバーは、数十のコアと巨大なメモリを持つことができます。