システム管理とは、1つ以上のハードウェアおよびソフトウェアシステムの管理のことを示します。 InterSystemsシステム管理についてのドキュメント
これは InterSystems FAQ サイトの記事です
ミラーリングが同期の対象とするのはデータベースファイルのみです。
アプリケーションに必要なその他のファイル（CSPファイル、画像ファイル、ドキュメントファイルなど）をミラーセットを構成する二台のサーバー間で同期させるには、
などの方法が考えられます。 また、2の方法では Windows 上では RoboCopy、Linuxの場合には rsync という同期ソフトを使った実例があります。
Prometheus は時系列データの収集に適した監視システムです。
このシステムのインストールと初期構成は比較的簡単です。 このシステムにはデータ視覚化用の PromDashと呼ばれる画像サブシステムが組み込まれていますが、開発者は Grafana と呼ばれる無料のサードパーティ製品を使用することを推奨しています。 Prometheus は多くの要素（ハードウェア、コンテナ、さまざまな DBMS の構成要素）を監視できますが、この記事では Caché インスタンス（正確に言えば Ensemble インスタンスですが、メトリックは Caché からのものになります）の監視に注目したいと思います。 ご興味があれば、このまま読み進めてください。
非常に単純なケースでは、Prometheus と Caché は単一のマシン（Fedora Workstation 24 x86_64）上に存在します。 Caché のバージョンは以下のとおりです。
インストールと構成
今回は、InterSystems IRIS に特有のことではなく、職場で Windows 10 Pro または Enterprise を搭載した PC またはノートパソコンがサーバーとして使用されている環境で Docker を使用する場合に重要と思われる点について触れたいと思います。
ご存知かと思いますが、コンテナテクノロジーは基本的に Linux の世界で生まれ、最近では Linux のホストで使用されており、その最大のポテンシャルを伺わせています。 Windows を普段から使用するユーザーの間では、Microsoft と Docker 両社によるここ数年の重大な試みにより、Windows のシステムで Linux イメージを基にコンテナを実行することがとても簡単になったと理解されています。しかし、生産システムでの使用がサポートされておらず、それが大きな問題となっています。特に、Windows と Linux のファイルシステムに大きな違いがあるため、安心してホストシステム内でコンテナの外に持続データを保管するということができないのです。 ついには、コンテナを実行するために、_Docker for Windows _自体で Linux の小さな仮想マシン (MobiLinux) が使用されるようになり、Windows ユーザーに対しては透過的に実行されます。また、先ほど述べたように、データベースの存続がコンテナよりも短くて構わないのであれば、パーフェクトに動作します。
では、何が言いたいかというと、問題を回避して処理を単純化するには、完全な Linux システムが必要になるが、Windows ベースのサーバーを使用していると、仮想マシンを使用する以外に方法がない場合が多い、ということです。 少なくとも、Windows の WSL2 がリリースされるまでの話ですが、それはまた別の機会に触れたいと思います。もちろん、十分堅牢に動作するまでは時間がかかるでしょう。
この記事では、必要に応じて、Windows サーバーの Ubuntu システムで Docker コンテナを使用できる環境をインストールする方法について分かりやすく説明します。 それでは、始めましょう。
この文書では、インターシステムズの製品の中で、InterSystems CachéおよびIRIS data platformに関するライセンスポリシーを説明します。
インターシステムズのライセンスポリシーは、パートナー（ソリューションおよびインプリメンテーション）契約の際の契約書一式あるいはエンドユーザーに直接販売する際の契約書一式に含まれる製品に関する条件（この文書は製品別に存在します）という文書で規定されています。
なおこの文書は一般には公開していません。
ここでは、CachéおよびIRIS data platformのライセンスポリシーについてこの文書に書かれていることを要約および補足して説明します。
まずCachéシステムおよびIRIS data platformはこの文書で規定されているライセンスポリシーにでき得る限り忠実にそうようにライセンスチェック機構を実装しています。
しかしながら様々な技術的な制約によりライセンスポリシーとこれら製品のライセンスシステムを完全に一致させることはできません。
そしてもしシステム上のライセンスチェック機構の動作とライセンスポリシー上に不一致が発生した場合には、いかなる場合でもライセンスポリシーが優先されます。
これはInterSystems FAQ サイトの記事です
%ZSTARTルーチンを インスタンス開始時に起動しないように構成設定用ファイルを手動で変更します。
【注意】
インスタンスの起動環境の変更は、通常管理ポータルで行うものなので、以下に説明する方法は、%ZSTART の SYSTEM ラベルの動作を無効化する方法以外では利用しないようにしてください（別のパラメータを誤って修正してしまった場合、起動できなくなる可能性がありますのでご注意ください）。
1. インスタンス のインストールディレクトリ以下にある構成設定用ファイル（cache.cpf/iris.cpf）をテキストエディタで開きます。
※構成ファイルは、事前にバックアップ(コピー)していただくことを推奨します。
2. [Startup]セクションにあるSystemStartの値を0に変更し、保存します。
3. ファイル変更後、一旦 インスタンスを通常の方法で停止し、再度開始してください。
SystemStart パラメータの詳細については、下記ドキュメントについてもご参照ください。
パラメータ・ファイル・リファレンス_SystemStart【IRIS】
これまでさまざまなストレージ技術とそのパフォーマンス特性の例を紹介してきましたが、今回は新しい HPE Cloudline 3150 Gen10（AMD プロセッサベースのシングルソケットサーバーで 3.2TB の Samsung PM1725a NVMe ドライブを 2 台搭載）など、内部コモディティベースのサーバーストレージの活用が増加傾向にあることを確認しました。
これは、InterSystems FAQサイトの記事です。
プログラムでロック情報を取得するには以下2種類の方法があります。
#dim rset As %SQL.StatementResult set stmt=##class(%SQL.Statement).%New() set st=stmt.%PrepareClassQuery("%SYS.LockQuery","List") set rset=stmt.%Execute() while rset.%Next() { write !,rset.%Get("FullReference") write !,rset.%Get("Owner") write !,rset.%Get("DelKey"),! }より詳細なロック情報を取得する場合には List クエリではなく Detail クエリを使用します。
set st=stmt.%PrepareClassQuery("%SYS.LockQuery","List") を
これはInterSystems FAQ サイトの記事です。
InterSystemsの製品には同時ユーザー数でライセンスの容量を決定する製品とサーバーのCPUコア数で容量を決定する製品の2種類があります。
同時ユーザー数ライセンスタイプの場合、CPUコア数により使用可能なライセンスのグレードに制限があります。
物理サーバーの場合には、そのサーバーが保持しているCPUコア数の総数をカウントします。
そして、その総数が該当グレードの最大CPUコア数を超えている場合には、その上位グレードを使用しなければなりません。
サーバー仮想化ソフトウェア（VMWare、Hyper-Vなど）を利用する場合には、その仮想サーバーに割り当てられたCPUコア数をカウントします。
同様にその総数が該当グレードの最大CPUコア数を超えている場合には、その上位グレードを使用しなければなりません。
CPUコア数ライセンスタイプの場合、コア数によりライセンスの容量が決まります。
CPUコア数の数え方は、同時ユーザーライセンスタイプと同じです。
物理サーバーの場合は、そのサーバーが保持しているCPUコア数の総数をカウントします。
サーバー仮想化ソフトウェアを利用する場合には、その仮想サーバーに割り当てられたCPUコア数をカウントします。
【関連情報】（コミュニティ／FAQトピックをリンクしています
これは、InterSystems FAQサイトの記事です。
以下に当てはまる場合、差分バックアップではなくフルバックアップが取られます。
・リストの中に１つでもフルバックアップを取っていないデータベース(DB)が含まれるとき
・リストの中に読み込み専用のDBが含まれるとき
→読込専用DBはバックアップが取れないため、対象リストのDBは毎回フルバックアップが取られます
ReadOnlyマウントしたDBをバックアップしようとすると、以下のようなログが出力されます。
WARNING - the following directories could not be backed up c:\intersystems\ensemble\mgr\xxx\ (Database is readonly)
読込専用DBはバックアップリストから除く必要があります。
もし、読込専用DBをバックアップする場合は、別途バックアップする必要があります。
これは、InterSystems FAQサイトの記事です。
[管理ポータル] > [システムオペレーション] > [ライセンス使用量] ページで表示される各項目の意味は以下のとおりです。
① 現在使用中のライセンス数：現時点のライセンスユニット使用数です。
② 最大ライセンス使用：インスタンスが起動した後、現在に至るまでで最もライセンス使用の大きかった時点の
"現在使用中のライセンス数"です。
③ 許可されたライセンス数（Cache.Key/iris.keyの値）：該当システムで許可されている最大ライセンスユニット数です。
④ 現在の接続：現時点のクライアントからの接続数です。
⑤ 最大接続：インスタンスが起動した後、現在に至るまでで最も接続数の大きかった時点の"現在の接続"です。
(A) ローカル：表示しているサーバのインスタンスで消費しているライセンスの情報です。
(B) リモート：マルチサーバライセンスを使用して複数インスタンスでライセンス共有している場合の、共有している全インスタンスで消費しているライセンスの合計値の情報です。
※ライセンス共有を行うには、ライセンスサーバの設定が必要です。詳細は下記トピックをご参考になさってください。
複数インスタンスでライセンスを共有する場合に必要な設定
これは、InterSystems FAQサイトの記事です。
IRISTempデータベースのサイズを小さくする方法は２つあります。
一つは、IRISTempデータベースを再作成する方法です。
手順としては、下記を実行します。
これにより、3．のIRIS起動時に、IRISTempデータベースが初期サイズ(1024KB)で再作成されます。
もう一つの方法は、構成パラメータの設定による方法です。
構成パラメータ「MaxIRISTempSizeAtStart」を設定することにより、IRIS起動時のIRISTempデータベースの最大サイズを設定できます。
システムは、設定後、次のIRIS起動時に、設定された値(MB)にIRISTempの切り捨てを行います。 指定した MaxIRISTempSizeAtStart よりも現在のサイズが小さい場合は、切り捨ては行われません。
また、0 を指定すると切り捨てが行われないため、サイズは変わらないまま起動します。（デフォルト）
設定は、以下メニューから行います。
管理ポータル
[システム管理]>[構成]>[追加の設定]>[開始]>"MaxIRISTempSizeAtStart"
詳細は下記ドキュメントページをご確認ください。
MaxIRISTempSizeAtStart
これはInterSystems FAQ サイトの記事です。
バックアップには、以下4種類の方法があります。
詳細は、以下ドキュメントをご参照ください。
バックアップの方法について【IRIS】
バックアップの方法について
1、2、4は、インスタンスを停止せずにバックアップが行えます（末尾の関連情報もご参照ください）。3 は、インスタンスを停止した後でバックアップを行う方法です。
またシステム構成や障害バターンを基にバックアップを設計、計画する上での注意点、自動化のサンプルやバックアップを実施する上で役立つ各種関連技術についてはInterSystems Symposia 2014 発表資料 をご参照ください（※1）。
※1：InterSystems Symposia 2014でご紹介した内容で、Cachéと記載がありますがバックアップ方法についてはIRISも同様です。
【関連情報】（コミュニティ／FAQトピックをリンクしています）
これは InterSystems FAQ サイトの記事です。
管理ポータルから行う手動のパージ（Purge）と、タスクを利用する方法があります。
データを手動でパージするには、[Interoperability] > [管理] > [管理データの削除] ページを使用します。
（このページではバックグラウンド・ジョブとしてパージを実行しますので、ページがタイムアウトしても問題ありません。）
タスクでパージする場合は、[システムオペレーション] > [タスクマネージャ] > [新しいタスク] の画面でInteroperabilityプロダクションのネームスペースを指定し、タスクタイプに「Ens.Util.Tasks.Purge」を指定します。
タスクの場合は、「TypesToPurge」の項目で以下のパージ対象タイプを選択できます（図参照）。
詳細は、以下のドキュメントをご参照ください。
※注意
こんにちは！ この記事は「Prometheus で InterSystems Caché を監視する」の続きになります。 ここでは ^mgstat ツールの動作結果を視覚化する方法を見ていきます。 このツールを使用すると、Caché のパフォーマンス統計、具体的なグローバルとルーチンの呼び出し数（ローカルおよびECP 経由）、書き込みデーモンのキュー長、ディスクに保存されるブロックと読み取られるブロックの数、ECP トラフィックの量などを取得できます。 ^mgstat は（対話的に、またはジョブによって）単独で起動したり、別のパフォーマンス測定ツールである ^pButtons と並行して起動したりできます。
これはInterSystems FAQ サイトの記事です。
IRISのサービスを /usr/lib/systemd/system/iris.service に作成し systemctl ユーティリティにて設定を行います。
手順は以下になります。 ※ 作業は root ユーザまたは root 権限を持つユーザで行ってください。
1. IRISの自動起動・自動停止のスクリプトファイル「irisstartstop」を作成します。
irisstartstop
これはInterSystems FAQ サイトの記事です。
1変数に最大 3,641,144 文字まで格納できます。
この制限は、InterSystems IRIS上で取り扱う全ての文字列が対象となるため、ローカル変数やメソッドの引数・戻り値も対象となります。
最大文字について詳しくは、以下ドキュメントをご参照ください。
これは、InterSystems FAQサイトの記事です
Windowsでは、以下イメージ名のプロセスを監視対象としてください。
[irisdb.exe]
重要なシステムプロセスが含まれています。
※ 監視対象にすべき重要なシステムプロセスを確認する方法は、添付をご参照ください。
[IRISservice.exe]
IRISインスタンスをサービス経由で扱う為のプロセスになります。
このプロセスが終了すると、IRISインスタンス自体には直接影響はありませんが、IRIS の停止(サービスの停止)ができなくなります。
[ctelnetd.exe]
%Service_Telnet サービスが有効になっている場合に起動し、Telnet 経由で IRIS へアクセスする為のデーモンプロセスになります。
このプロセスが終了すると、IRIS インスタンスへの Telnet アクセスができなくなります。
[iristrmd.exe]
%Service_Console サービスが有効(既定で有効)になっている場合に起動し、サーバのローカル端末(サーバの IRIS ランチャーからターミナル)より IRIS へアクセスする為のデーモンプロセスです。
このプロセスが終了すると、IRIS インスタンスへのローカル端末アクセスができなくなります。
これはInterSystems FAQ サイトの記事です。
IRIS の開始ができず、messages.log に以下のようなエラーが出力された場合の対処方法についてご説明します。
このメッセージは、ジャーナルファイルの破損による IRIS 開始時のリカバリ処理がエラーになっていることを示しています。
これはInterSystems FAQ サイトの記事です。
2つのステップにて作業します。
クラス定義を別システムへ移行するため、XML形式またはUDL形式（拡張子.cls）のファイルにエクスポートします。
スタジオでのエクスポート手順は以下の通りです。
[ツール] > [エクスポート]
> [追加]ボタンで移行したいクラスを複数選択
> [ローカルファイルにエクスポート]にチェック
> ファイルの種類がXMLであることを確認し、ファイル名を入力し、[OK]
この後、別システム上のスタジオで、エクスポートしたXML、UDLファイルをインポートします。
この手順で、クラス定義は移行できます。
スタジオでのインポート手順は以下の通りです。
[ツール] > [ローカルからインポート]
> 上記手順で出力したXML、UDLファイルを指定します。
次に実際のデータを移行します。
オブジェクトデータは既定では、以下の命名規則のグローバル変数内に格納されています。
データ ：^クラス名D
インデックス：^クラス名I
ストリーム ：^クラス名S
例）User.testクラスのデータは以下の3つのグローバルに格納されます。
^User.testD, ^User.testI, ^User.testS
これはInterSystems FAQ サイトの記事です。
この記事では「グローバルを誤って削除してしまった！.png)
」という場合の対処方法をご紹介します。
誤って削除してしまった特定のグローバルを復旧するためには、バックアップファイルとジャーナルを使用します。
復旧は、^ZJRNFILTユーティリティによるジャーナルリストアで条件を指定してジャーナルレコードをリストアする方法で行います。
この方法で、ある時点のデータベースのバックアップに対して、削除が含まれるジャーナルレコードについて特定グローバルを削除するまでのものを適用することができます。
^ZJRNFILTユーティリティの詳細については、以下のドキュメントをご参照ください。
^ZJRNFILT を使用したジャーナル・レコードのフィルタ処理について【IRIS】
^ZJRNFILT を使用したジャーナル・レコードのフィルタ処理について
【実施例】
・2020/10/14 時点のバックアップが存在している（バックアップは2020/10/15 0:30に実行したとします）
ジャーナル：2020/10/15 の1日分が存在している(2020/10/14のバックアップ以降のもの)
・対象のグローバル：^TEST1
イメージは以下の通りです。
Ansible は Caché とアプリケーションコンポーネントをいかに迅速にデータプラットフォームのベンチマークにデプロイするかという課題を解決するのに役立ちました。 同じツールと方法をテストラボ、トレーニングシステム、開発環境、またはその他の環境の立ち上げも使うことができます。 顧客サイトにアプリケーションをデプロイする場合、デプロイの大部分を自動化し、アプリケーションのベストプラクティス標準に合わせてシステム、Caché、アプリケーションを確実に構成することができます。
これはInterSystems FAQ サイトの記事です。
DBLatency の Warning メッセージは、ヘルス・モニタプロセスが定期的にデータベースからのランダム読み取りが完了するまでに要した時間（ミリ秒）を計測していて、設定されている閾値（1000 msec）を超えた場合に出力されます。
上記例では、C:\xxx\IRIS.DAT（または C:\xxx\CACHE.DAT）へのディスク読み取り I/O に 1510 msec かかったことを示していて、メッセージ出力時のディスク I/O 応答速度が遅いことが考えられます。
ディスク I/O 応答速度が遅い原因としては、ディスク I/O 負荷が高いことが考えられます。
Amazon Web Services（AWS）クラウドは、コンピューティングリソース、ストレージオプション、ネットワークなどのインフラストラクチャサービスの幅広いセットをユーティリティとしてオンデマンドかつ秒単位の従量課金制で提供しています。 新しいサービスは、先行投資なしで迅速にプロビジョニングできます。 これにより、大企業、新興企業、中小企業、公営企業の顧客は、変化するビジネス要件に迅速に対応するために必要なビルディングブロックにアクセスすることができます。
更新: 2019年10月15日
Config.Configurationクラス、SYS.Databaseクラスのメソッドを使用して、ネームスペース・データベースの作成及び登録をターミナルから実行することができます。
以下はデータベースファル/CacheDB/AAA/cache.datを作成し、構成ファイル（cache.cpf）にデータベース AAA、及び、ネームスペースAAAの登録を行う一連の実行例です。 ＊実行は、%SYSネームスペースで行って下さい。＊
Set Directory="/CacheDB/AAA/"Setx=$ZF(-100, "/shell", "mkdir", Directory)
Set db=##Class(SYS.Database).%New()
Set db.Directory=Directory
Set status=db.%Save()
Set DBName="AAA"Set status=##class(Config.Configuration).AddDatabase(DBName,Directory)
Set NSName=DBName
Set status=##class(Config.Configuration).AddNamespace(NSName,DBName)これはInterSystems FAQ サイトの記事です。
InterSystemsでは、パフォーマンスの影響や動作不調を避けるために、データベースファイルを含む主要なコンポーネントをウイルススキャンの対象から除外していただくことを推奨しております。
具体的には、アンチウイルスソフトのスキャン対象から、以下のファイルを除外してください。
上記ファイルが、アンチウイルスソフトで除外設定されていない場合、「SERIOUS DISK WRITE ERROR...」のようなエラーが発生する場合があります。
このエラーは、実際にハード的なディスク障害が原因であることもありますが、それ以外にアンチウィルスソフトのウィルスチェックなどによって、ディスクへの書き込みが阻止された場合にも起こります。
詳細は、下記ドキュメントページをご参照ください。
インターシステムズ製品と連係して動作するようにサードパーティ・ソフトウェアを構成する方法【IRIS】
インターシステムズ製品と連係して動作するようにサードパーティ・ソフトウェアを構成する方法
最近の大規模なベンチマーク活動で、アプリケーションのスケーリングに悪影響を与える過度の %sys CPU 時間が観察されました。
問題
TZ 環境変数が設定されていないため、 localtime() システムコールに多くの時間が費やされていることがわかりました。 観察結果を確認するための単純なテストルーチンが作成されましたが、TZ が設定されている場合と TZ が未設定の場合とでは経過時間と必要な CPUリソースが驚くほど違っていました。 TZ が設定されていない場合、localtime() から /etc/local_time への stat() システムコールの継承使用は非常に負荷が高いことがわかりました。
推奨事項
InterSystems は、x86 または Linux on Power のいずれの Linux インストール環境でも、TZ 環境変数を適切に設定して最適なパフォーマンスを確保することを強く推奨しています。 詳細については、「man tzset」を参照してください。
現在の Caché 2016.1のフィールドテストでは日付および時刻関連の関数に関する最適化が行われており、初期テストでは大幅に改善していることがわかっています。 以下は、TZ が設定されていない場合に PowerPC上のLinuxで新しい内部関数の呼び出しをテストした結果の出力例です。
企業はグローバルコンピューティングインフラストラクチャを迅速かつ効率的に成長させて管理すると同時に、資本コストと費用を最適化して管理する必要があります。 Amazon Web Services（AWS）および Elastic Compute Cloud（EC2）コンピューティングおよびストレージサービスは、非常に堅牢なグローバルコンピューティングインフラストラクチャを提供することにより、最も要求の厳しいCachéベースのアプリケーションのニーズを満たします。
この記事では、スナップショットを使用したソリューションとの統合の例を使って、_外部バックアップ_による Caché のバックアップ方法を紹介します。 このところ私が目にするソリューションの大半は、Linux の VMware にデプロイされているため、この記事の大半では、例として、ソリューションが VMware スナップショットテクノロジーをどのように統合しているかを説明しています。
Caché をインストールすると、Caché データベースを中断せずにバックアップできる Caché オンラインバックアップが含まれています。 しかし、システムがスケールアップするにつれ、より効率的なバックアップソリューションを検討する必要があります。 Caché データベースを含み、システムをバックアップするには、スナップショットテクノロジーに統合された_外部バックアップ_をお勧めします。
詳しい内容は外部バックアップのオンラインドキュメンテーションに説明されていますが、 主な考慮事項は次のとおりです。
Google Cloud Platform（GCP）は、IaaS（サービスとしてのインフラストラクチャ）向けの機能性豊かな環境をクラウドとして提供しています。最新の InterSystems IRIS データプラットフォームなど、InterSystems の全製品に完全に対応していますが、 あらゆるプラットフォームやデプロイメントモデルと同様に、パフォーマンス、可用性、運用、管理手順などの環境に関わるすべての側面が正しく機能するように注意を払う必要があります。 この記事では、こういった各分野の詳細について説明しています。
この記事ではVMware ESXi 5.5以降の環境にCaché 2015以降を導入する場合の構成、システムのサイジング、およびキャパシティ計画のガイドラインを示します。
ここでは、皆さんがVMware vSphere仮想化プラットフォームについてすでに理解していることを前提としています。 このガイドの推奨事項は特定のハードウェアやサイト固有の実装に特化したものではなく、vSphereの導入を計画して構成するための完全なガイドとして意図されたものでもありません。これは、皆さんが選択可能なベストプラクティス構成をチェックリストにしたものです。 これらの推奨事項は、皆さんの熟練したVMware実装チームが特定のサイトのために評価することを想定しています。
InterSystems データプラットフォームとパフォーマンスに関する他の連載記事のリストはこちらにあります。
注意: 本番データベースインスタンス用のVMメモリを予約し、Cachéに確実にメモリを使用させてデータベースのパフォーマンスに悪影響を与えるスワップやバルーニングの発生を防ぐ必要があることを強調するため、この記事を2017年1月3日に更新しています。 詳細については、以下のメモリセクションを参照してください。