ソフトウェアのデプロイは、ソフトウェアシステムを使用できるようにするためのすべてのアクティビティです。 一般的なデプロイプロセスは、可能なトランジションのあるいくつかの相互に関連するアクティビティで構成されます。
これは、InterSystems FAQ サイトの記事です。
InterSystems製品では、％Installerユーティリティによりインストール・マニフェストを定義することができます。これを利用することにより、複雑な構成設定を自動化することが可能になります。
これは特に、複数の同様なアプリケーションデプロイを行うときに大変有効です。
インストール・マニフェストの詳細については、下記のドキュメントページをご参照ください。
インストール・マニフェストの作成および使用
また、下記の トピックでも、詳しく記載されています。
%InstallerでInterSystems Cachéにアプリケーションをデプロイする
※記事ではCachéについて記述していますが、内容はIRISでも同様です。
コミュニティの皆さん、こんにちは！
DeepSee Web についてのパート 2 では、DSW のカスタマイズオプションについて説明します。
カスタマイズには、ウィジェットのカスタマイズとダッシュボードパネルのカスタマイズの 2 種類があります。
開発者コミュニティ分析におけるダッシュボードのカスタマイズ例。
ウィジェットのカスタマイズ
DSW の各グラフウィジェットは、凡例、凡例要素、値、上位/全部の切り替えの要素によって調整することができます。
調整パネルは、グラフウィジェットの右上にあります。
ではその仕組みを見てみましょう。
凡例
小文字の「i」は凡例の切り替えを表します。 クリックすると凡例が表示/非表示になります。 また、凡例の特定の要素を表示/非表示にすることもできます。
上位行フィルタ
星ボタンは、上位/全部の切り替えボタンで、ピボットの最初の測定の上位 20 件フィルターを素早くオン/オフにできます。
値の切り替え
「V」は <s>vendetta</s> 値です。 クリックすると、行の値が表示/非表示になります。
ウィジェットのレイアウト
DSW は最初に DeepSee ダッシュボードリソースからウィジェットレイアウトを取得して、DSW 設定の列カウント（デフォルトは 12）とウィジェットの最小高さ（100）に合わせて拡大縮小されます。
ウィジェットのレイアウトは好みに合わせて移動して設定できます。 フィルタコントロールを配置する必要がある場合などには特に便利です（フィルタコントロールは、ウィジェットの代わりにダッシュボードにフィルタが配置される場合に自動的に表示されます）。
ダッシュボードパネルのカスタマイズ
DSW では、ダッシュボードパネルとタイル/カバーの外観をカスタマイズできます。
以下は、DeepSee ダッシュボードのクラシックパネルビューです。
DSW では、ダッシュボードパネルビューを 3 つの方法でカスタマイズできます（カスタマイズは設定で変更できます）。
Show images（画像を表示）をオンにすると、DeepSee の画像がダッシュボードカバーに表示されます。
すると、ダッシュボードパネルに画像が表示されます。
Show folders（フォルダを表示）を選択すると、同じダッシュボードパネルがフォルダで編成されます。
また、ダッシュボードカバーの色やサイズを調整し、対話型にすることができます。
ダッシュボードパネルの右下からタイルエディターを開きます。
カスタマイズのデプロイ
デプロイについてはどうでしょうか。 設定やカスタマイズを開発からプロダクションソリューションに配布するには？
これを行うには、Settings（設定）メニューで現在のカスタマイズをエクスポートできます。
すべての設定が settings.json ファイルにエクスポートされるため、ターゲットプロダクションサーバーにデプロイすることができます。 DSW は、設定が含まれるファイルを /csp/dsw/configs/namespace.json ファイルで探します。
例: これは samples.json ファイルです。これを DSW インストールの /csp/dsw/config/samples.json に配置すれば、DSW がこのネームスペースのダッシュボードの設定を自動的に読み込むようになります。
尽きることのないカスタマイズ
デザイン、設定、調整などを行えるすべてのケースにおいて、カスタマイズが完成することは決してありません。 そのため、この分野において他の機能をご希望の場合は、課題をお送りいただくか、この機能を実装してプルリクエストをお送りください。
DSW の機能についてはさらに記事が追加されます。 パート 1 を読んで、今後の更新にご期待ください！
開発者の皆さん、こんにちは！
この記事では、IRIS Security Package 用 REST API をセットアップする方法を学習します。 簡単な HTTP リクエストによって、ユーザー、役割、アプリケーションの追加などを作成し、ObjectScript でクライアントアプリケーションを生成できるようになります。
必要なのは:
OpenExchangeで既存のアプリケーションとライブラリのセットを使用する予定です。 package manager (ZPM)を使用すると、それらのインストールが非常に簡単になります。 インスタンスに ZPM がない場合は、IRIS ターミナルにこのラインをコピーすることで簡単にインストールすることができます。
set $namespace="%SYS" do ##class(Security.SSLConfigs).Create("ssl") set r=##class(%Net.HttpRequest).%New(),r.Server="pm.community.intersystems.com",r.SSLConfiguration="ssl" do r.Get("/packages/zpm/latest/installer"),$system.OBJ.LoadStream(r.HttpResponse.Data,"c")
パッケージ関連の REST サービスは、Config-API アプリケーションのバージョン 1.4.0 以降で利用できます。 このアプリケーションをZPMコマンドで簡単にインストールすることにします。
zpm "install config-api"
デフォルトでは、Config-API をインストールしても REST サービスは公開されないので、Web アプリケーション「/config-api」を作成する必要があります。 管理ポータルでの手動操作を避けるために、即時使用可能なスクリプトが用意されています。
Do ##class(Api.Config.Developers.Install).installMainRESTApp()
セキュリティパッケージのRESTサービスが、「/config-api/security/」というパスで利用できるようになりました。
これで、「/config-api」Webアプリケーションが作成されると、管理ポータルで詳細を確認できるようになります。
デフォルトでは、ユーザが%Admin_Secureリソースを持っている場合、アプリケーションはログインとパスワード（基本認証）によってのみアクセスできます。
もちろん、これだけでは十分ではありません。 リクエストにはHTTPSプロトコルを使用し、WebGatewayとIRISインスタンス間の通信を暗号化する必要があります。API Manager(IAM)を利用するのも有効かもしれません。そうすることで、例えば特定のIPアドレスからのHTTPリクエストのみを受け付けるなど、よりスムーズなアクセス制御が可能になります。 設定方法については、この記事の範囲外なので、詳しくは説明しません。しかし、このテーマについては、コミュニティや公式ドキュメントでより多くの記事を見つけることができます。しかし、もしあなたが私にコメントを残して、私はあなたにWebGateway HTTPSとSSLTLSを持つDockerベースのリポジトリを提供することを望みます。
RESTディスパッチクラス "Api.Config.REST.Main" は、 "OnPreDispatch" メソッドを実装しています。このメソッドは、リクエスト処理の前に呼び出されます。各リクエストに対して実行したい共通のコードをここに置くだけです。pContinueに0を設定すると、リクエストは処理されないことを覚えておいてください。
Class Api.Config.REST.Main Extends %CSP.REST
{
....
ClassMethod OnPreDispatch(pUrl As %String, pMethod As %String, ByRef pContinue As %Boolean) As %Status
{
Set sc = $$$OK, class = ##class(Api.Config.REST.OnPreDispatchAbstract).GetSubClass()
Set pContinue = $$$YES
Return:class="" sc
Return $CLASSMETHOD(class, "OnPreDispatch", pUrl, pMethod, .pContinue)
}
}
デフォルトの実装では、"Api.Config.REST.OnPreDispatchAbstract "のサブクラスが存在するかどうかをチェックします。 もし存在すれば、それが実行されます。カスタムコードを実行するフックがあるので、API Managerがない場合、追加のアクセスチェックやロギングを行う代替手段にもなります。
以下は、受信したリクエストのみをログに記録する実装例です。
Class dc.sample.RestSecurity Extends Api.Config.REST.OnPreDispatchAbstract
{
ClassMethod OnPreDispatch(pUrl As %String, pMethod As %String, ByRef pContinue As %Boolean) As %Status
{
Set sc = $$$OK
/// カスタムアクセス認証はここで実装してください。
Set key = $Increment(^RestSecurity.log)
Set ^RestSecurity.log(key) = $ZDateTime($Horolog,3,1) _ " " _ pMethod _ " " _pUrl _ "( IP : " _ $Get(%request.CgiEnvs("REMOTE_ADDR")) _ ")"
merge ^RestSecurity.log(key, "CgiEnvs") = %request.CgiEnvs
merge ^RestSecurity.log(key, "Data") = %request.Data
// 実行を停止する例:
// Set %response.Status = "401 Unauthorized"
// Set pContinue = $$$NO
Quit sc
}
}
このAPIは http://localhost:52773/config-api/security/ で公開されている 仕様（swagger 2.0）で提供されています（必要に応じてポート番号を修正してください）。そのため、例えばOpenExchangeで公開されているswagger-uiというアプリケーションを使用すれば、簡単にクライアントアプリケーションを生成することができます。
swagger-uiをインストールします。
zpm "install swagger-ui"
次に、URLhttp://localhost:52773/csp/swagger-ui/index.htmlでブラウザを開きます。
ページを開くと、ほとんどの場合、エラーが表示されます。
このエラーは、デフォルトでswagger-uiが存在しないURLから仕様を取得しようとするために発生します。このエラーを回避するには、RESTサービスのURLを調査することで、swagger-uiを強制的に開かせることができます：
Do ##class(Api.Config.Developers.Install).SetSwaggerUIDefaultPath("/config-api/security/")
ここでブラウザを更新してください。 %Admin_secure リソースを持つユーザーでログインしてください。
この段階では、ユーザー、役割、リソース、SSL構成、およびWebアプリケーションに対して、**C**reate **R**ead **U**pdate **D**elete の操作が可能であることが、このインターフェイスで確認することができます。
サービスやシステム設定の場合は少し違っていて、読み込み（GET）と変更（PUT）しかできません。
このインターフェースは、かなり詳細なswagger仕様のおかげで自己文書化されています。
POST /user をクリックすれば、詳細な説明、リクエストのサンプルボディ、モデルの完全なドキュメントを得ることができるので、ここで各リクエストをテストする方法を説明することは有益ではありません。 この記事では、SQL 特権という特殊なケースについてのみ説明します。
POST/sqlprivileges
SQL 特権を設定します。
以下は、"select " 特権を追加するためのボディの例です。
{
"Grantable": "1",
"Grantee": "MyRoleName",
"Grantor": "_system",
"Namespace": "USER",
"Privilege": "s",
"SQLObject": "1,schema_name.table_name"
}
特権は次の値を取ることができます：s (select)、 i (insert)、 u (update)、 d (delete)、 r (reference)、 および e (execute).
SQLObjectは、テーブルを表す "1"、ビューを表す "3"、ストアドプロシージャを表す "9 "から始まります。
多数のテーブルに特権を割り当てる必要がある場合、あまり便利ではありません......。 この場合は「(PUT)/sqlhelper」を使用するのがよいでしょう。
DELETE/sqlprivileges/{id}
削除は、名前空間、SQLObject、特権、付与者、付与者から構成されるIDによって行われます。前回の特権の作成に対応するIDは「USER||1,schema_name.table_name||s||MyRoleName|_system」であります。特殊文字のエスケープに注意してください。
PUT/sqlhelper
このサービスでは、1つまたは複数のスキーマの全テーブルに一連の権限を割り当てることができます。以下はボディの例です。
{
"Grantable": "1",
"Grantee": "MyNewRole",
"Grantor": "_system",
"Namespace": "USER",
"Table": {
"Schemas": [
"schema_name",
"schema_name_2"
],
"Privileges": [
"S",
"I",
"U",
"D"
]
}
}
Swagger editorでは、swaggerの仕様から様々な言語でクライアントを生成することができますが、残念ながらObjectScriptはそのリストに含まれていません。 ただし、OpenExchangeにあるアプリケーション「OpenApi-client-gen」を使えば生成することが可能です。現在のところ、swagger 2.0仕様にのみ対応しています。
Install openapi-client-gen:
zpm "install openapi-client-gen"
クライアントアプリケーションを生成します：
Set features("simpleHttpClientOnly") = 1
Set sc = ##class(dc.openapi.client.Spec).generateApp("IrisSecurity", "https://raw.githubusercontent.com/lscalese/iris-config-api/master/swagger-security.json", .features)
Write !,"Status : ",$SYSTEM.Status.GetOneErrorText(sc)
以下に、HTTPリクエストでWebアプリケーションの一覧を取得し、その結果をターミナルに表示するコードの例を示します。
Class iris.dc.sample.ObjectScriptRestClient
{
ClassMethod GetRequestObj() As %Net.HttpRequest
{
Set httpRequest = ##class(%Net.HttpRequest).%New()
Set httpRequest.Username = "_system"
Set httpRequest.Password = "SYS"
Set httpRequest.Server = "iris-security-rest-server"
Set httpRequest.Port = 52773
Set httpRequest.Https = 0
Quit httpRequest
}
ClassMethod ExampleGetWebAppList() As %Status
{
Set sc = $$$OK
Set httpClient = ##class(IrisSecurity.HttpClient).%New()
Set httpRequest = ..GetRequestObj()
Do httpRequest.SetHeader("accept", "application/json")
Set msg = ##class(IrisSecurity.msg.GetListOfWebAppsRequest).%New()
Set sc = httpClient.GETGetListOfWebApps(msg,.response,.httpRequest,.httpresponse)
Write !,"Status : ",$SYSTEM.Status.GetOneErrorText(sc)
Quit:$$$ISERR(sc) sc
Write !,"Http Status Code : ",response.httpStatusCode
Write !
zw response
If response.httpStatusCode = 200 {
Set formatter=##class(%JSON.Formatter).%New()
Do formatter.Format({}.%FromJSON(response.body))
}
Quit sc
}
}
もしあなたがDockerユーザーなら、この記事で見てきたことはすべて次のGitHubリポジトリで公開されています：https://github.com/lscalese/iris-sample-security-rest-api.
このように実行します。
git clone https://github.com/lscalese/iris-sample-security-rest-api.git
cd iris-sample-security-rest-api
docker-compose up -d
これで、URL http://localhost:32773/swagger-ui/index.html でブラウザを開き、REST API を直接テストすることができます。
また、iris-cliサービスにおいてターミナルを開き、生成されたObjectScriptクライアントアプリケーションをテストすることもできます。
docker exec -it iris-security-rest-client iris session iris
Do ##class(iris.dc.sample.ObjectScriptRestClient).ExampleGetWebAppList()
JSON形式で表示されたWebアプリケーションのリストが表示されるはずです。
記事で使用されているすべてのソースコード: https://github.com/antonum/ha-iris-k8s
前の記事では、従来型のミラーリングではなく分散ストレージに基づいて、高可用性のあるk8sでIRISをセットアップする方法について説明しました。 その記事では例としてAzure AKSクラスタを使用しました。 この記事では引き続き、k8sで可用性の高い構成を詳しく見ていきますが、 今回は、Amazon EKS（AWSが管理するKubernetesサービス）に基づき、Kubernetes Snapshotに基づいてデータベースのバックアップと復元を行うためのオプションが含まれます。
早速作業に取り掛かりましょう。 まず、AWSアカウントが必要です。AWS CLI、kubectl、およびeksctlツールがインストールされている必要があります。 新しいクラスタを作成するために、次のコマンドを実行します。
eksctl create cluster \ --name my-cluster \ --node-type m5.2xlarge \ --nodes 3 \ --node-volume-size 500 \ --region us-east-1
このコマンドは約15分掛けてEKSクラスタをデプロイし、それをkubectlツールのデフォルトのフォルダに設定します。 デプロイを確認するには、次のコードを実行します。
kubectl get nodes NAME STATUS ROLES AGE VERSION ip-192-168-19-7.ca-central-1.compute.internal Ready <none> 18d v1.18.9-eks-d1db3c ip-192-168-37-96.ca-central-1.compute.internal Ready <none> 18d v1.18.9-eks-d1db3c ip-192-168-76-18.ca-central-1.compute.internal Ready <none> 18d v1.18.9-eks-d1db3c
次に、Longhorn分散ストレージエンジンをインストールします。
kubectl create namespace longhorn-system kubectl apply -f https://raw.githubusercontent.com/longhorn/longhorn/v1.1.0/deploy/iscsi/longhorn-iscsi-installation.yaml --namespace longhorn-system kubectl apply -f https://raw.githubusercontent.com/longhorn/longhorn/master/deploy/longhorn.yaml --namespace longhorn-system
そして最後に、IRIS自体をインストールします。
kubectl apply -f https://github.com/antonum/ha-iris-k8s/raw/main/tldr.yaml
この時点で、Longhorn分散ストレージとIRISデプロイがインストールされたEKSクラスタが完全に機能できる状態になります。 前の記事に戻って、クラスタとIRISデプロイにあらゆるダメージを与えて、システムがどのように修復するのかを確認するとよいでしょう。 「障害をシミュレートする」セクションをご覧ください。
IRIS EKSとLonghornはARMアーキテクチャをサポートしているため、ARMアーキテクチャに基づき、AWS Gravition 2インスタンスを使用して同じ構成をデプロイできます。
EKSノードのインスタンスタイプを 'm6g' ファミリーに変更し、IRISイメージをARMベースに変更するだけです。
eksctl create cluster \
--name my-cluster-arm \
--node-type m6g.2xlarge \
--nodes 3 \
--node-volume-size 500 \
--region us-east-1
tldr.yaml
containers: #- image: store/intersystems/iris-community:2020.4.0.524.0 - image: store/intersystems/irishealth-community-arm64:2020.4.0.524.0 name: iris
または、単に以下を使用します。
kubectl apply -f https://github.com/antonum/ha-iris-k8s/raw/main/tldr-iris4h-arm.yaml
以上です！ ARMプラットフォームで実行するIRIS Kubernetesクラスタが出来上がりました。
本番環境グレードのアーキテクチャでよく見過ごされがちな部分に、データベースのバックアップを作成して必要なときに素早く復元するか複製する機能があります。
Kubernetesでは、一般的にPersistent Volume Snapshots（永続ボリュームスナップショット）を使用してこれを行います。
まず、必要なすべてのk8sコンポーネントをインストールする必要があります。
#Install CSI Snapshotter and CRDs kubectl apply -n kube-system -f https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/master/client/config/crd/snapshot.storage.k8s.io_volumesnapshotcontents.yaml kubectl apply -n kube-system -f https://github.com/kubernetes-csi/external-snapshotter/raw/master/client/config/crd/snapshot.storage.k8s.io_volumesnapshotclasses.yaml kubectl apply -n kube-system -f https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/master/client/config/crd/snapshot.storage.k8s.io_volumesnapshots.yaml kubectl apply -n kube-system -f https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/master/deploy/kubernetes/snapshot-controller/setup-snapshot-controller.yaml kubectl apply -n kube-system -f https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/master/deploy/kubernetes/snapshot-controller/rbac-snapshot-controller.yaml
次に、LonghornのS3バケット資格情報を構成します（詳細な手順を参照）。
#Longhorn backup target s3 bucket and credentials longhorn would use to access that bucket #See https://longhorn.io/docs/1.1.0/snapshots-and-backups/backup-and-restore/set-backup-target/ for manual setup instructions longhorn_s3_bucket=longhorn-backup-123xx #bucket name should be globally unique, unless you want to reuse existing backups and credentials longhorn_s3_region=us-east-1 longhorn_aws_key=AKIAVHCUNTEXAMPLE longhorn_aws_secret=g2q2+5DVXk5p3AHIB5m/Tk6U6dXrEXAMPLE
以下のコマンドは、前の手順から環境変数を拾い、それを使ってLonghorn Backupを構成します。
#configure Longhorn backup target and credentials cat <<EOF | kubectl apply -f - apiVersion: longhorn.io/v1beta1 kind: Setting metadata: name: backup-target namespace: longhorn-system value: "s3://$longhorn_s3_bucket@$longhorn_s3_region/" # backup target here --- apiVersion: v1 kind: Secret metadata: name: "aws-secret" namespace: "longhorn-system" labels: data: # echo -n '<secret>' | base64 AWS_ACCESS_KEY_ID: $(echo -n $longhorn_aws_key | base64) AWS_SECRET_ACCESS_KEY: $(echo -n $longhorn_aws_secret | base64) --- apiVersion: longhorn.io/v1beta1 kind: Setting metadata: name: backup-target-credential-secret namespace: longhorn-system value: "aws-secret" # backup secret name here EOF
たくさんの作業に見えるかもしれませんが、基本的にLonghornに対し、指定された資格情報で特定のS3バケットを使用し、バックアップのコンテンツを保存するように指示しています。
以上です！ Longhorn UIに移動すると、バックアップを作成して復元などを行えるようになっています。
Longhorn UIに接続する方法を簡単におさらいしましょう。
kubectl get pods -n longhorn-system # note the full pod name for 'longhorn-ui-...' pod kubectl port-forward longhorn-ui-df95bdf85-469sz 9000:8000 -n longhorn-system
これによって、Longhorn UIへのトラフィックはhttp://localhost:9000に転送されるようになります。
Longhorn UIを介して行うバックアップと復元は、最初のステップとしては十分かもしれませんが、もう一歩先に進み、k8s Snapshot APIを使用して、プログラムでバックアップと復元を実行してみましょう。
まず、スナップショットそのものが必要です。 iris-volume-snapshot.yaml
apiVersion: snapshot.storage.k8s.io/v1beta1
kind: VolumeSnapshot
metadata:
name: iris-longhorn-snapshot
spec:
volumeSnapshotClassName: longhorn
source:
persistentVolumeClaimName: iris-pvcこのボリュームスナップショットは、IRISデプロイに使用するソースボリュームである 'iris-pvc' を参照しています。 そのため、これを適用するだけですぐにバックアッププロセスが開始します。
IRIS書き込みデーモンの凍結と解凍をスナップショットの前後に実行することをお勧めします。
#Freeze Write Daemon echo "Freezing IRIS Write Daemon" kubectl exec -it -n $namespace $pod_name -- iris session iris -U%SYS "##Class(Backup.General).ExternalFreeze()" status=$? if [[ $status -eq 5 ]]; then echo "IRIS WD IS FROZEN, Performing backup" kubectl apply -f backup/iris-volume-snapshot.yaml -n $namespace elif [[ $status -eq 3 ]]; then echo "IRIS WD FREEZE FAILED" fi #Thaw Write Daemon kubectl exec -it -n $namespace $pod_name -- iris session iris -U%SYS "##Class(Backup.General).ExternalThaw()"
復元プロセスは非常に簡単です。 基本的には、新しいPVCを作成して、スナップショットをソースとして指定しています。
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: iris-pvc-restored
spec:
storageClassName: longhorn
dataSource:
name: iris-longhorn-snapshot
kind: VolumeSnapshot
apiGroup: snapshot.storage.k8s.io
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 10Gi次に、このPVCに基づいて新しいデプロイを作成するだけです。 これを順に行うこちらのGitHubリポジトリにあるテストスクリプトをご覧ください。
この時点で、同一のIRISデプロイが2つ存在することになります。1つはもう片方のデプロイのclone-via-backupです。
どうぞお楽しみください！
以下の記事では、DeepSee のより柔軟なアーキテクチャ設計の概要を説明します。 前の例で説明したとおり、この実装には、DeepSee キャッシュや DeepSee の実装と設定、および同期グローバル用の個別のデータベースが含まれています。 この例では、DeepSee インデックスを保存するための新しいデータベースを紹介します。 DeepSee インデックスがファクトテーブルや次元テーブルとともにマッピングされないように、グローバルマッピングを再定義します。
APP-FACT データベースはファクトテーブルと次元テーブルしか保存しないのに対し、アナリティクスサーバーは、中間的な例で前に定義したデータベースに加え、インデックスを保存する APP-INDEX データベースを導入します。 インデックスをファクトテーブルから分離するのは、インデックスのサイズが大きくなる可能性があるため、パフォーマンスを向上させるために APP-FACT のブロックサイズを変更することができるからです。
前の例のように、ファクトテーブルとインデックスのジャーナリングはオプションで有効にできます。 詳細については、前の記事の注意事項をお読みください。
次のスクリーンショットは、上記の実装例のマッピングを示しています。 ^DeepSee.Index グローバルのマッピングは、新たに作成された APP-INDEX データベースに保存されるように変更されています。 中間の例と同様に、^DeepSee.Fact* と ^DeepSee.Dimension* グローバルのマッピングは引き続き、ファクトテーブルと次元テーブルを APP-FACT データベースに保存するために使用されています。 クエリログと最後の MDX クエリは、オプションで DeepSee キャッシュとともに保存されます。
このアーキテクチャの例は最も高い柔軟性を備えていますが、ネームスペースごとに 5 つのデータベースを作成する必要があります。 2 つ目の例のように、DeepSee キャッシュはジャーナリングが無効になっている専用のデータベースにマッピングされており、同期グローバルは APP-DSTIME にマッピングされています。
ファクトテーブルとインデックスをマッピングすると、DeepSee の実装と設定をジャーナリングされる専用のデータベース（ APP-DEEPSEE）に保存できるため、DeepSee 実装の復元を簡単に行えるようになります。 多くの場合、対応するグローバルをファクトテーブルと共に APP-FACT に保存するだけで充分であるため、インデックス用のデータベースを個別に作成するのはオプションです。
この連載の最後の記事には、3 つの例で使用したデータベースの要約とリストを記載します。
以下の記事では、DeepSee の中程度の複雑さのアーキテクチャ設計を説明します。 前の例で説明したとおり、この実装には、DeepSee キャッシュや DeepSee の実装と設定用の個別のデータベースが含まれています。 この記事では、同期に必要なグローバルの保存用と、ファクトテーブルとインデックスの保存用に、2 つの新しいデータベースを紹介します。
前の例で紹介した APP-CACHE と APP-DEEPSEE データベースのほかに、APP-DSTIME と APP-FACT データベースを定義します。
APP-DSTIME データベースには DeppSee の同期グローバルである ^OBJ.DSTIME と ^DeepSee.Update が含まれます。 これらのグローバルは、運用サーバーにある（ジャーナリングされた）データベースからミラーリングされています。 APP-DSTIME データベースは、^DeepSee.Update を使用して caché バージョンの読み取りと書き込みができる必要があります。
APP-FACT データベースは、ファクトテーブルとインデックスを保存します。 ファクトテーブルからインデックスを分離するのは、インデックスのサイズが大きくなる可能性があるためです。 APP-FACT を定義することで、ジャーナル設定の柔軟性をより高めたり、デフォルト以外のブロックサイズを定義したりすることができます。 APP-FACT データベースのジャーナリングはオプションで有効にできますが、 この選択は主に、中断が発生した場合にキューブを再構築する際に、アナリティクスが利用できないままとなるかどう通って決まります。 この例では、ファクトテーブルとインデックスのジャーナリングは無効になっています。無効にする一般的な理由には、キューブサイズが小さいこと、キューブの再構築を比較的素早く行えること、そして定期的な再構築が頻繁に行われることがあります。 より詳しい説明は、下の方にある注意事項をお読みください。
次のスクリーンショットは、上記の実装例のマッピングを示しています。
DeepSee 同期グローバルの ^OBJ.DSTIME と ^DeepSee.Update は、APP-DSTIME データベースにマッピングされています。 ^DeepSee.LastQuery と ^DeepSee.QueryLog グローバルは、実行されるすべての MDX クエリのログを定義します。 この例では、これらのグローバルは DeepSee キャッシュとともに APP-CACHE データベースにマッピングされています。 これらのマッピングはオプションです。
^DeepSee.Fact* と ^DeepSee.Dimension* グローバルは、ファクトテーブルと次元テーブルを保存しますが、^DeepSee.Index グローバルは DeppSee インデックスを定義します。 これらのグローバルは、APP-FACT データベースにマッピングされています。
基本的な例のように、DeepSee キャッシュは、ジャーナリングが無効になっている専用のデータベースに正しく保存されています。 DeepSee の実装と設定は、DeepSee 実装を復元できるように、ジャーナリングされたデータベースに個別にマッピングされています。
同期をサポートするグローバルは APP-DSTIME にマッピングされ、プライマリでジャーナリングされています。
ファクトテーブルとインデックスを専用のデータベースにマッピングすると、DeepSee の実装と設定をジャーナリングされる専用のデータベース（ APP-DEEPSEE）に保存できるため、DeepSee 実装の復元を簡単に行えるようになります。
最後の 3 つ目の例では、APP-FACT データベースのマッピングを再定義し、DeepSee インデックスのデータベースを作成します。
キューブを構築するとキューブのファクトとインデックステーブルが削除されて再作成されることに注意してください。 つまり、ジャーナリングが有効である場合、^DeepSee.Fact* や ^DeepSee.Index などのグローバルの SET や KILL がジャーナルファイルに記録されるということです。 その結果、キューブを再構築すると、ジャーナルファイルのエントリが膨大化し、ディスク容量に問題が生じる可能性があります。
ファクトテーブルとインデックスを 1 つか 2 つの別々のデータベースにマッピングすることをお勧めします。
ファクトおよびインデックスデータベースにおいては、ジャーナリングはオプションであり、ビジネスのニーズに基づきます。 キューブが比較的小さく、素早く構築できる場合や、キューブの定期的な再構築が計画されている場合には、ジャーナリングを無効にすることをお勧めします。
キューブが比較的大きく、再構築に時間が掛かる場合には、このデータベースのジャーナリングを有効にします。 キューブが安定しており、定期的に同期されるだけで構築は行われない場合には、ジャーナリングを有効にしておくのが理想的と言えます。 キューブを安全に構築する方法の 1 つとして、ファクトデータベースのジャーナリングを一時的に無効にすることが挙げられます。
以下の記事は、DeepSee の基本的なアーキテクチャを実装するためのガイドです。 この実装には、DeepSee キャッシュ用のデータベースと DeepSee 実装と設定用のデータベースが含まれています。
アナリティクスサーバー用のこの構成には、APP-CACHE と APP-DEEPSEE データベースが含まれています。 DeepSee が円滑に実行するためには、DeepSee キャッシュを決してジャーナリングしないことが重要な設定となります。 ジャーナリングしてしまうと、ハイパージャーナリングやディスク容量の問題が発生するだけでなく、DeepSee エンジンのパフォーマンスが低下してしまいます。 このため、DeepSee キャッシュは、ジャーナリングが無効になっている別の DeepSee Cache データベース「APP-CACHE」に格納されます。
APP-DEEPSEE は、^DeepSee.* グローバルが含まれる、DeepSee の実装と設定用のデータベースです。 これらのグローバルは、定義と設定、Cube Manager、ユーザー設定など、ほとんどの DeepSee 実装を定義しています。 次に示すスクリーンショットに見られるように、すべてのデータベースは読み取り/書き込みが可能であり、APP-DEEPSEE でのみジャーナリングが有効となるように決定されていることに注意してください。 このデータベースにはすべての定義、設定、およびユーザーデータが含まれているため、これをジャーナリングすることをお勧めします。
次のスクリーンショットは、APP ネームスペース上のこの基本アーキテクチャ実装のマッピングを示しています。 ^DeepSee.Cache.* と ^DeepSee.JoinIndex は DeepSee キャッシュを APP-CACHE データベースにマッピングしています。 ^DeepSee.* グローバルはとりわけ、DeepSee の実装と設定を APP-DEEPSEE データベースにマッピングしています。
基本アーキテクチャのこの例では、DeepSee キャッシュは専用のデータベースに保存されています。 このため、^DeepSee.Cache* と ^DeepSee.JoinIndex グローバルのジャーナリングを無効にすることができます。
中断が発生した場合に DeepSee 実装（キューブ、サブジェクトエリア、DeepSee アイテム、ユーザー設定など）の復元を実現できるのが、APP-DEEPSEE データベースのジャーナリングです。
この例に説明されている構成には、いくつかの欠点があります。 まず、同期をサポートするグローバルが処理されていない点です。 2 つ目は、APP-DEEPSEE データベースには、ファクトテーブル、インデックス、およびその他の DeepSee グローバルも含まれている点です。 そのため、APP-DEEPSEE のサイズが肥大し、ジャーナリングと復元が実用的でなくなる可能性があります。 この構成は、たとえばキューブに大量のデータが含まれていない場合などに適用できます。
この連載の次の例では、キューブ同期グローバル、ファクトテーブル、およびインデックスを個別のデータベースにマッピングする方法を説明します。
以下の記事は、この連載の締めくくりとして、完全に柔軟なアーキテクチャの例で確認されたすべてのデータベースのリストを掲載しています。
以下で説明するデータベースは、ネームスペース間で共有する必要のあるアプリケーションコードを除き（例では APP-CODE データベースに格納されています）、ネームスペースごとに定義されている必要があります。 DeepSee 実装が実行するすべてのネームスペースはグローバルマッピングを使用し、グローバルが正しいデータベースに保存されて読み取られるようにする必要があります。
このデータベースはすべての DeepSee キャッシュ（^DeepSee.Cache.* および ^DeepSee.JoinIndex グローバル）を保存する必要があります（注意: ドキュメントのこちらのページに、さらに多くのグローバルが DeepSee キャッシュとしてリストされていますが、^DeepSee.Cache.* グローバルが明らかに最も重要なグローバルです）。
DeepSee キャッシュグローバルを専用のデータベースにマッピングすることを強くお勧めします。 DeepSee キャッシュグローバルは決してジャーナル化されてはいけません。ジャーナル化してしまうと、DeepSee のパフォーマンスが低下し、ジャーナルファイルが巨大化する可能性があります。
^DeepSee.Cache.* と ^DeepSee.JoinIndex グローバルをこのデータベースにマッピングします。 必要に応じて、^DeepSee.LastQuery と ^DeepSee.QueryLog グローバルもこのデータベースにマッピングします。これらは実行されたすべての MDX クエリのログを保存するグローバルです。
このデータベースには、DeepSee 実装のほとんどが含まれている ^DeepSee.* グローバルが含まれています。 このデータベースには、すべての DeepSee キューブまたはサブジェクトエリアの定義のほか、Cube Manager（^DeepSee.CubeManager*）、キューブの定義と設定（^DeepSee.Cubes、^DeepSee.Dimensions）、DeepSee のアイテム（^DeepSee.Folder*、^DeepSee.FolderItem*）、ピボット変数（^DeepSee.Variables）、用語リスト（DeepSee.TermList）、ユーザー設定（^DeepSee.DashboardSettings）、DeepSee オーバーライド（^DeepSee.Overrides）などの多数の機能に関する情報も含まれています。
これらの機能は別の読み取り/書き込み可能なデータベースに保存し、そのデータベースにジャーナリングを実行して定期的にバックアップすることをお勧めします。 そうすれば、何らかの中断が生じた場合でも、すべての定義、設定、およびユーザーデータを復元することが可能になります。
残りのすべての ^DeepSee* グローバルをこのデータベースにマッピングします。
DeepSee は、ソーステーブルでキューブを最新の状態に維持するために、^OBJ.DSTIME と ^DeepSee.Update グローバルを使用しています。 運用データベースでは、このデータベースに ^OBJ.DSTIME グローバルを保存し、アナリティクスサーバーにミラーリングします。 システムがアドホックまたは最新バージョンの Caché で実行している場合、これらには ^DeepSee.Update が使用されているため（通常、Caché 2016.1.2 以降で利用可能）、このデータベースにも ^DeepSee.Update が保存されます。 この場合、^OBJ.DSTIME を保存しているアナリティクスサーバーのデータベースは、読み取り/書き込み可能であり、^OBJ.DSTIME が ^DeepSee.Update にコピーされた後に、それをパージできる必要があります。 データベースホスティングデータ（この例では APP-DATA）が読み取り専用の場合、このデータベースを使用する必要があることに注意してください。使用しない場合、^OBJ.DSTIME をパージするのは不可能です。
運用サーバーでは、ジャーナリングが有効になっている必要があります。 ^OBJ.DSTIME と ^DeepSee.Update をこのデータベースにマッピングします。
DeepSee のキューブはソースクラスに基づいていますが、ファクトテーブルと次元テーブルにデータを入力して使用します。 これらのテーブルには、キューブに組み込まれた各レコードの情報が含まれており、ランタイム時に DeepSee によって使用されます。
ファクトテーブル、次元テーブル、およびインデックス用の専用データベースを定義するのは通常、データベースごとに異なるジャーナリングの設定を適用するためです。 ジャーナリングが有効である場合のキューブの構築について、以下の注意事項をお読みください。 ファクトテーブル、次元テーブル、およびインデックスを別のデータベースにマッピングするもう 1 つの理由は、デフォルト以外のブロックサイズを定義することができるからです（デフォルトの 8000 ブロックではなく 16000 ブロックにするなど）。 異なるブロックサイズを使用することで、MDX クエリのパフォーマンスを向上させることができます。
ファクトテーブルと次元テーブルは、^DeepSee.Fact* と ^DeepSee.Dimension* グローバルに保存されています。 DeepSee インデックスは ^DeepSee.Index に保存され、キューブがリレーションを定義するときに ^DeepSee.JoinIndex グローバルが使用されます。 これらのグローバルはこのデータベースにマッピングします。
DeepSee インデックスは、キューブのファクトテーブルのインデックスです。
DeepSee インデックスを別のデータベースに保存するのは、^DeepSee.Index グローバルのサイズが大きくなる可能性があるためです。 異なるジャーナリング設定を使用し、デフォルト以外のブロックサイズを定義すると、復元を簡単に行えるようになり、パフォーマンスの改善にも役立ちます。
ジャーナリングはオプションです。前のデータベースと同じ設定を選択してください。
^DeepSee.Index グローバルはこのデータベースにマッピングします。
キューブを構築するとキューブのファクトとインデックステーブルが削除されて再作成されることに注意してください。 つまり、ジャーナリングが有効である場合、^DeepSee.Fact* や ^DeepSee.Index などのグローバルの SET や KILL がジャーナルファイルに記録されるということです。 その結果、キューブを再構築すると、ジャーナルファイルのエントリが膨大化し、ディスク容量に問題が生じる可能性があります。
ファクトテーブルとインデックスを 1 つか 2 つの別々のデータベース（上記のデータベース 4 とデータベース 5）にマッピングすることをお勧めします。
ファクトおよびインデックスデータベースにおいては、ジャーナリングはオプションであり、ビジネスのニーズに基づきます。 キューブが比較的小さく、素早く構築できる場合や、キューブの定期的な再構築が計画されている場合には、ジャーナリングを無効にすることをお勧めします。
キューブが比較的大きく、再構築に時間が掛かる場合には このデータベースのジャーナリングを有効にします。 キューブが安定しており、定期的に同期されるだけで構築は行われない場合には、ジャーナリングを有効にしておくのが理想的と言えます。 キューブを安全に構築する方法の 1 つとして、ファクトデータベースとインデックスデータベース（順にデータベース 4 と 5）のジャーナリングを一時的に無効にすることが挙げられます。
| データベース |
この連載では、Caché と DeepSee を使用したビジネスインテリジェンスの実装に関して考慮する必要のあるデータベースとマッピング関連のベストプラクティスを説明しました。 この連載で推奨したデータベースより少ない数のデータベースを使って DeepSee 実装をデプロイすることはもちろん可能ですが、実装に制限がかかる可能性があります。
これは InterSystems FAQ サイトの記事です。
ソースプログラムのコンパイル後に生成される *.obj のみをエクスポート／インポートすることでソースの隠蔽化を実現できます。
コマンド実行例は、EX1Sample.mac と EX2Sample.mac のコンパイルで生成される EX1Sample.obj と EX2Sample.obj をエクスポート対象に指定し、第2引数のファイルにエクスポートしています。
別ネームスペースに移動したあと、エクスポートした XML ファイルを利用してインポートを実行しています。
CloudFormationの記事は、Linux系のものが多いですが、Windowsでも自動化したいという需要がありそうですので、オリジナル記事を元に、CloudFormationを使用してミラークラスターをWindowsサーバにデプロイする例を実装してみました。また、簡単な実行例も追加しました。
ソースコード一式はこちらのGitレポジトリにあります。
更新: 2021年3月1日 ワンライナーで踏み台ホスト経由でWindowsに公開鍵認証する方法を追記しました
更新: 2022年11月29日 QuickStartの形式に合わせて大幅に変更しました。以前の内容はこちらに保存してあります。
更新: 2022年12月21日 踏み台ホストの使用を止め、代わりにAWS System Manager(SSM)を有効化しました。プライベートサブネット上のインスタンスへのアクセスが簡素化されます。以前の内容はこちらに保存してあります。
QuickStartのデプロイ方法に従います。
非公開のS3バケットにIRISのキット及びライセンスキーをアップロードします。
S3BucketName=<my bucket>
aws s3 mb s3://$S3BucketName
aws s3 cp iris.key s3://$S3BucketName
aws s3 cp ISCAgent-2022.1.0.209.0-lnxrh7x64.tar.gz s3://$S3BucketName
aws s3 cp IRIS-2022.1.0.209.0-win_x64.exe s3://$S3BucketName
S3BucketName=<my bucket>
aws s3 mb s3://$S3BucketName
aws s3 cp iris.key s3://$S3BucketName
aws s3 cp ISCAgent-2022.1.0.209.0-lnxrh7x64.tar.gz s3://$S3BucketName
aws s3 cp IRIS-2022.1.0.209.0-lnxrh7x64.tar.gz s3://$S3BucketName
S3BucketName=<my bucket>
aws s3 mb s3://$S3BucketName
aws s3 cp iris.key s3://$S3BucketName
aws s3 cp ISCAgent-2022.1.0.209.0-lnxrh7x64.tar.gz s3://$S3BucketName
aws s3 cp IRIS-2022.1.0.209.0-lnxubuntu2004x64.tar.gz s3://$S3BucketName
このテンプレートは、AmazonLinuxを使用しています。RedHat7もしくはUbuntuを利用する場合は、別途「カスタマイズ候補」のチャプターの作業が必要です
また、事前にAWS上に用意されているテンプレートではなく、カスタマイズを行ったテンプレートを使用するので、下記を実行します。
QSS3BucketNameはS3BucketNameと同じでも、異なっていても構いません。
$ git clone https://github.com/IRISMeister/AWSIRISDeployment.git --recursive
$ cd AWSIRISDeployment
Windowsにデプロイする場合
QSS3BucketName=<my bucket>
aws s3 cp quickstart-intersystems-iris-windows s3://$QSS3BucketName/quickstart-intersystems-iris-windows --recursive
aws s3 cp submodules/quickstart-aws-vpc/templates s3://$QSS3BucketName/quickstart-intersystems-iris-windows/submodules/quickstart-aws-vpc --recursive
aws s3 cp submodules/quickstart-linux-bastion/templates s3://$QSS3BucketName/quickstart-intersystems-iris-windows/submodules/quickstart-linux-bastion --recursive
aws s3 cp submodules/quickstart-linux-bastion/scripts s3://$QSS3BucketName/quickstart-intersystems-iris-windows/submodules/quickstart-linux-bastion --recursive
Linuxにデプロイする場合
QSS3BucketName=<my bucket>
aws s3 cp quickstart-intersystems-iris s3://$QSS3BucketName/quickstart-intersystems-iris --recursive
aws s3 cp submodules/quickstart-aws-vpc/templates s3://$QSS3BucketName/quickstart-intersystems-iris/submodules/quickstart-aws-vpc --recursive
aws s3 cp submodules/quickstart-linux-bastion/templates s3://$QSS3BucketName/quickstart-intersystems-iris/submodules/quickstart-linux-bastion --recursive
aws s3 cp submodules/quickstart-linux-bastion/scripts s3://$QSS3BucketName/quickstart-intersystems-iris/submodules/quickstart-linux-bastion --recursive
以下、既存VPCにWindows版IRISのミラー構成をデプロイする際の実行例です。
VPCを新規作成する場合は、下記のVPC関連の事前準備は不要です。
既存VPC上に、以下のリソースを事前に用意しました。
デプロイ実行時にNATゲートウエイが無いと、スタックの作成に失敗します。必ず用意してください。
パブリックサブネット
プライベートサブネット
ルートテーブル/ルート
ルートテーブル/サブネットの関連付け
NATゲートウエイ
S3BucketName=iwamoto-cf-templates
aws s3 mb s3://$S3BucketName
aws s3 cp ISCAgent-2022.1.0.209.0-lnxrh7x64.tar.gz s3://$S3BucketName
aws s3 cp iris.key s3://$S3BucketName
aws s3 cp IRIS-2022.1.0.209.0-win_x64.exe s3://$S3BucketName
git clone https://github.com/IRISMeister/AWSIRISDeployment.git
cd AWSIRISDeployment
# キットファイル格納先と同じbucketを使用しています
QSS3BucketName=iwamoto-cf-templates
aws s3 cp quickstart-intersystems-iris-windows s3://$QSS3BucketName/quickstart-intersystems-iris-windows --recursive
aws s3 cp submodules/quickstart-aws-vpc/templates s3://$QSS3BucketName/quickstart-intersystems-iris-windows/submodules/quickstart-aws-vpc --recursive
aws s3 cp submodules/quickstart-linux-bastion/templates s3://$QSS3BucketName/quickstart-intersystems-iris-windows/submodules/quickstart-linux-bastion --recursive
aws s3 cp submodules/quickstart-linux-bastion/scripts s3://$QSS3BucketName/quickstart-intersystems-iris-windows/submodules/quickstart-linux-bastion --recursive
このような内容になります。
aws s3 ls s3://$QSS3BucketName --recursive
2022-06-15 07:48:57 675737136 IRIS-2022.1.0.209.0-win_x64.exe
2022-10-12 01:09:57 16139988 ISCAgent-2022.1.0.209.0-lnxrh7x64.tar.gz
2022-03-29 07:11:24 546 iris.key
2022-11-25 09:15:50 0 quickstart-intersystems-iris-windows/
2022-11-25 09:16:05 0 quickstart-intersystems-iris-windows/scripts/
2022-11-28 05:34:49 6008 quickstart-intersystems-iris-windows/scripts/MirrorInstaller.xml
2022-11-28 13:34:52 0 quickstart-intersystems-iris-windows/submodules/
2022-11-28 13:34:52 0 quickstart-intersystems-iris-windows/submodules/quickstart-aws-vpc/
2022-11-28 13:34:52 0 quickstart-intersystems-iris-windows/submodules/quickstart-aws-vpc/templates/
2022-11-28 13:34:52 59966 quickstart-intersystems-iris-windows/submodules/quickstart-aws-vpc/templates/aws-vpc.template.yaml
2022-11-28 13:34:52 0 quickstart-intersystems-iris-windows/submodules/quickstart-linux-bastion/
2022-11-28 13:34:52 0 quickstart-intersystems-iris-windows/submodules/quickstart-linux-bastion/scripts/
2022-11-28 13:34:52 531 quickstart-intersystems-iris-windows/submodules/quickstart-linux-bastion/scripts/auditing_configure.sh
2022-11-28 13:34:52 881 quickstart-intersystems-iris-windows/submodules/quickstart-linux-bastion/scripts/banner_message.txt
2022-11-28 13:34:52 11763 quickstart-intersystems-iris-windows/submodules/quickstart-linux-bastion/scripts/bastion_bootstrap.sh
2022-11-28 13:34:52 0 quickstart-intersystems-iris-windows/submodules/quickstart-linux-bastion/templates/
2022-11-28 13:34:52 24068 quickstart-intersystems-iris-windows/submodules/quickstart-linux-bastion/templates/linux-bastion.template
2022-11-25 09:16:16 0 quickstart-intersystems-iris-windows/templates/
2022-11-28 09:35:42 6059 quickstart-intersystems-iris-windows/templates/iris-cluster-arbiter-node.template.yaml
2022-11-28 09:35:42 21529 quickstart-intersystems-iris-windows/templates/iris-cluster-iris-node.template.yaml
2022-11-28 09:35:42 13736 quickstart-intersystems-iris-windows/templates/iris-cluster-main.template.yaml
2022-11-28 09:35:43 10403 quickstart-intersystems-iris-windows/templates/iris-entrypoint-new-vpc.template.yaml
繰り返し実行することを考慮して、パラメータを全て指定した状態のテンプレートを作成しておくと便利です。
vi test-iris-cluster-main-windows.yaml
編集後のファイルをうっかり公開してしまわないよう注意してください
編集時の注意
NATゲートウェイは存在するだけでコストが発生します。(VM起動直後のS/Wインストール時など)必要な時に作成し、不要になったらすぐ削除したかったので、別のCFテンプレートにしています。
テンプレートソースには「テンプレートファイルのアップロード」を選択し、先ほど編集したファイル(test-iris-cluster-main-windows.yaml)を指定します。
「スタックの詳細を指定」画面でパラメータを設定します。
| パラメータ | 設定値例 |
|---|---|
| BastionSubnetIdParameter | subnet-0f7c4xxxxxxxxxxxx,subnet-05b42xxxxxxxxxxxx |
| IRISPasswordParameter | SYS1 |
| InstanceSubnetIdParameter | subnet-0180bxxxxxxxxxxxx,subnet-03272xxxxxxxxxxxx,subnet-08e8fxxxxxxxxxxxx |
| QSS3BucketName | iwamoto-cf-templates |
| QSS3BucketRegion | ap-northeast-1 |
| QSS3KeyPrefix | quickstart-intersystems-iris-windows/ |
| S3BucketNameParameter | iwamoto-cf-templates |
| SshKeyParameter | aws |
| VpcIdParameter | vpc-0e538xxxxxxxxxxxx |
「スタックオプションの設定」画面に特に設定はありません。実行がうまくいかない場合は、スタックの作成オプションの「失敗時のロールバック」を無効にしておくと、作成された環境がロールバックされずに残りますので、問題の解析がしやすくなります(不要になったら、忘れずに削除すること)。
「レビュー」画面で、「The following resource(s) require capabilities:」で、下記にチェックをいれる必要があります。
「スタックの作成」ボタンを押します。複数のネストされたスタックの作成が開始されます。
| Stack | キー | 値 | 説明 |
|---|---|---|---|
| IRIStack | JDBCEndpoint | jdbc:IRIS://xxxx-NLB-xxxxx.elb.ap-northeast-1.amazonaws.com:51773/DATA | JDBC Connection String |
| IRIStack | Node01InstanceId | i-xxxxxxxxxx | Node 01 Instance ID |
| IRIStack | Node01PrivateIP | 10.0.12.85 | Node 01 Private IP |
| IRIStack | Node02InstanceId | i-xxxxxxxxxx | Node 02 Instance ID |
| IRIStack | Node02PrivateIP | 10.0.10.159 | Node 02 Private IP |
これらの出力値を記録しておいてください。
Node01ホスト(ミラープライマリサーバ)の管理ポータルに接続します。下記のコマンドを実行します。
セッションマネージャのポート転送を利用します。事前にAWS CLIのインストール・構成とSSMプラグインのインストールが必要です。私はWindows10+WSL2(Ubuntu)を使用していますので、下記を実行しました。
$ curl "https://s3.amazonaws.com/session-manager-downloads/plugin/latest/ubuntu_64bit/session-manager-plugin.deb" -o "session-manager-plugin.deb"
$ sudo dpkg -i session-manager-plugin.deb
$ export instanceid=i-xxxxxxxxxx
$ aws ssm start-session --target $instanceid \
--document-name AWS-StartPortForwardingSession \
--parameters '{"portNumber":["52773"],"localPortNumber":["52773"]}'
SSHトンネルを作成する方法もあります。
BastionPublicIP=54.168.xxx.xxx
Node01PrivateIP=10.0.12.85
ssh -i aws.pem -L 52773:$Node01PrivateIP:52773 ec2-user@$BastionPublicIP
この時点で、http://localhost:52773/csp/sys/UtilHome.csp で管理ポータルにアクセスできます。アカウントはSuperUser、パスワードはスタックのパラメータで指定したものを使用します。ミラーの状態を確認するために、管理ポータルのホーム画面の右端に「ミラー・モニターを表示」というリンクがありますので、クリックします。以下の画面のように表示されていれば正常です。
RDP接続する場合は、(推奨に従って)Node01をプライベートサブネットに作成している場合、ssh同様、RDPも直接接続できません。フリートマネージャーをRDPの代替えとして利用可能です。
フリートマネージャーを使しない場合は、下記のようなコマンドをローカルで実行し、localhostから転送する必要があります。
$ export instanceid=i-xxxxxxxxxx
$ aws ssm start-session --target $instanceid \
--document-name AWS-StartPortForwardingSession \
--parameters '{"portNumber":["3389"],"localPortNumber":["33389"]}'
ssh -i aws.pem -L 33389:$Node01PrivateIP:3389 ec2-user@$BastionPublicIP
Windowsのパスワードは、AWSコンソールからのRDP接続方法で取得します。 その上で、RDPでlocalhost:33389に接続し、Administrator/取得したパスワード、でログインします。
SSMのセッションマネージャを使用します。
あるいは、~/.ssh/configを設定することで、SSM経由でSSHアクセスすることも可能です。
$ export instanceid=i-xxxxxxxxxx
$ ssh -i aws.pem ec2-user@$instanceid
BastionPublicIP=54.168.xxx.xx
Node01PrivateIP=10.0.12.85
ssh -i aws.pem -L 52773:$Node01PrivateIP:52773 ec2-user@$BastionPublicIP
ssh -i aws.pem -L 33389:$Node01PrivateIP:3389 ec2-user@$BastionPublicIP
ssh -i aws.pem -oProxyCommand="ssh -i aws.pem -W %h:%p ec2-user@$BastionPublicIP" ec2-user@$Node01PrivateIP
or
ssh -i aws.pem -oProxyCommand="ssh -i aws.pem -W %h:%p ec2-user@$BastionPublicIP" ubuntu@$Node01PrivateIP
BastionPublicIPは、事前に用意した踏み台ホストの公開IPです。
手順は省略します。実行にはJDBCドライバが必要です。
iris-cluster-iris-node.template.yamlでPSファイル等を作成しています。下記の箇所は、環境・目的に応じて変更してください。
Windows環境のローカライズ(timezone, firewall設定)
ドライブの作成、割り当て
Resources:
NodeInstance:
Properties:
BlockDeviceMappings:
IRISインストール先など
$irisdir="h:\InterSystems\IRIS"
$irissvcname="IRIS_h-_intersystems_iris"
$irisdbdir="I:\iris\db\"
$irisjrndir="J:\iris\jrnl\pri"
$irisjrnaltdir="K:\iris\jrnl\alt"
このpsファイルは、実行時に作成される/temp/envs.ps1と組み合わせれば、IRISの無人インストール用のスクリプトとして機能します。
プリインストールするソフトウェア
O/Sの指定
現在、O/Sは利便性によりAmazon Linuxを指定してあります。
O/SをRedHatに変更するには下記ファイルの内容を変更してください。
quickstart-intersystems-iris\templates\iris-cluster-iris-node.template.yaml
LatestAmiIdParameter:
Type: AWS::EC2::Image::Id
Default: ami-0be4c0b05bbeb2afd
O/SをUbuntuに変更するには下記ファイルの内容を変更してください。
quickstart-intersystems-iris\templates\iris-cluster-iris-node.template.yaml
LatestAmiIdParameter:
Type: 'AWS::SSM::Parameter::Value<AWS::EC2::Image::Id>'
Default: /aws/service/canonical/ubuntu/server/focal/stable/current/amd64/hvm/ebs-gp2/ami-id
IRISKitNameParameter:
Type: String
Default: IRIS-2022.1.0.209.0-lnxubuntu2004x64
デプロイ先をWindowsに変更する際に、Linux版との互換性を維持したままで、いくつかの修正を加えました。
Windowsの起動に時間がかかるため、デフォルトのInstance typeをm5.largeからm5.xlargeに変更。gp2をgp3に変更。IOPSを指定。
LatestAmiIdForIRISParameterパラメータを新設。Windowsのキット(日本語版、英語版等)の指定。
IRISKitNameParameterパラメータを新設。キット名の指定。
RDPアクセス用にSecurityGroupIngress(ポート:3389)を追加
SE.ShardInstallerクラス修正
CreateMirrorSet()
set mirror("ECPAddress") = hostName // Windows on AWS need this
JoinAsFailover()
set MirrorInfo("ECPAddress") = hostName // Windows on AWS need this
Roleを追加
キット用S3バケットに対するs3:GetObject
ec2:Describe*
ec2:DeleteRoute
ec2:CreateRoute
ec2:ReplaceRoute
セッションマネージャ有効化のため
AmazonSSMManagedInstanceCore
LBのヘルスチェックのデフォルト値を使用しています。quickstart-intersystems-iris-windows\templates\iris-cluster-main.template.yamlのコメントを解除して適切な値に調整してください。
#HealthCheckTimeoutSeconds: 10
#HealthCheckIntervalSeconds: 10
#UnhealthyThresholdCount: 3
以下、テンプレートと作成されるAWSリソースの関係です。
| テンプレート名 | 作成されるリソース |
|---|---|
| iris-cluster-iris-node.template.yaml | スタンドアロン |
| iris-cluster-iris-main.template.yaml | ミラー環境 |
| iris-entrypoint-new-vpc.template.yaml | VPC+ミラー環境 |
AWS System Managerを有効化しているため、いずれも踏み台ホストは作成しません。必要であれば、このテンプレートを参考にして作成しください。
環境の明滅を繰り返し実行する可能性がある場合、パラメータを全て指定した状態のテンプレートを別途作成しておくと便利です。
| テンプレート名 | O/S | 用途 |
|---|---|---|
| test-iris-cluster-iris-node-linux.yaml | Linux | スタンドアロン |
| test-iris-cluster-iris-node-windows.yaml | Windows | スタンドアロン |
| test-iris-cluster-iris-main-linux.yaml | Linux | ミラー環境 |
| test-iris-cluster-iris-main-windows.yaml | Windows | ミラー環境 |
| test-iris-entrypoint-new-vpc-linux.yaml | Linux | VPC+ミラー環境 |
| test-iris-entrypoint-new-vpc-windows.yaml | Windows | VPC+ミラー環境 |
例えば、スタンドアローン構成でIRISを起動したい場合は、下記のファイルを編集します。
$ #デプロイするサブネット(InstanceSubnetIdParameterの値)には既存のパブリックサブネットを指定してください
$ vi test-iris-cluster-iris-node-linux.yaml
スタック作成時に、test-iris-cluster-iris-node-windows.yamlを指定すれば、スタンドアローン構成でIRISを起動することが出来ます。
SSMのセッションマネージャを使用します。
踏み台ホストの使用を止めたため、下記内容は無効になりました。下記の方法を試す場合は、別途、こちらのようなテンプレートを利用して踏み台ホストを作成してください。
IRIS稼働ホストにOpenSSHをインストールすれば、踏み台ホスト経由で、IRISホストにSSHする事が可能です。ただし、Linux版に比べて、Windows版のIRISではCLIで実行できることが限られているため、効果は限定的です。
IRIS稼働ホストで実行。
PS C:\Users\Administrator> Add-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0
PS C:\Users\Administrator> Start-Service sshd
Windowクライアントからアクセスする際には、Windows版OpenSSHクライアント固有の問題「posix_spawn: No such file or directory」を回避するために、Git同梱のBashを使用しました。
user@DESKTOP-XXXX MINGW64 ~ ssh -oProxyCommand="ssh -i aws.pem -W %h:%p ec2-user@54.95.xxx.xxx" Administrator@10.0.0.62
Administrator@10.0.0.62's password: RDP接続の際に取得したパスワード
(load pubkey "aws.pem": invalid format が出ますが無視)
また、ひと手間いりますが、踏み台ホストの.ssh/authorized_keys(パブリックキー)を、デプロイ先のWindowsにコピーすれば、ワンライナーで公開鍵認証できます。
user@DESKTOP-XXXX MINGW64 ~ ssh -i aws.pem -oProxyCommand="ssh -i aws.pem -W %h:%p ec2-user@54.95.xxx.xxx" Administrator@10.0.0.62
Adminグループには特別の設定が必要でした。こちらのConfiguring the Serverを参考にしました。
cfn-init.logに下記のようなエラーが出ることがあるようです。
2021-02-12 02:50:32,957 [ERROR] -----------------------BUILD FAILED!------------------------
2021-02-12 02:50:32,957 [ERROR] Unhandled exception during build: 'utf8' codec can't decode byte 0x83 in position 8: invalid start byte
回避されることを期待して、Install-IRIS.ps1に、以下の命令を追加しています。
[Console]::OutputEncoding = [System.Text.Encoding]::UTF8
下記のサイトを参考にしています。
注意: 本ガイド (特に前提条件のセクション) を理解するには、AWS に関する中級から上級レベルの知識が必要になります。 S3 バケット、EC2 インスタンスの IAM ロール、VPC、サブネットを作成する必要があります。 また、InterSystems バイナリへのアクセス (通常は WRC サイトからダウンロード可) および IRIS のライセンスキーも必要になります。
2020 年 8月 12日
Anton Umnikov
テンプレートのソースコードは、こちらから入手していただけます: https://github.com/antonum/AWSIRISDeployment
目次
InterSystems IRIS デプロイガイド – AWS パートナーネットワーク
マルチ AZ 配置による耐障害性を備えたアーキテクチャダイアグラム (優先)
シングルインスタンンス、シングル AZ 配置のアーキテクチャダイアグラム (開発およびテスト)
IRIS Management Portal への安全なアクセス
InterSystems は、ユーザーの皆さまに InterSystems と AWS のベストプラクティスに則したかたちで独自の InterSystems IRIS® データプラットフォームをセットアップしていただけるよう CloudFormation テンプレートを提供しております。
本ガイドでは、CloudFormation テンプレートをデプロイするステップを詳しく解説していきます。
本ガイドでは、InterSystems IRIS CloudFormation テンプレートをデプロイする 2 種類の方法をご紹介します。 1 つ目は、複数のアベイラビリティーゾーン (AZ) を使い、プロダクションのワークロードを対象とした可用性の高い方法で、2 つ目は、開発とテストのワークロードを対象に、単一のアベイラビリティーゾーンにデプロイする方法です。
このセクションでは、当社のソリューションを実行、操作していただくための前提条件と要件について詳しく説明します。
デプロイ自体は 4 分程度で完了しますが、前提条件やテストの時間を入れると、最大 2 時間ほどかかります。
InterSystems のお客様には、https://wrc.intersystems.com より InterSystems IRIS のバイナリをご使用いただけます。 WRC の認証情報を使ってログインしてから、リンクに従って Actions -> SW Distributions -> InterSystems IRIS と順に移動してください。 このデプロイガイドは、InterSystems IRIS 2020.1 のビルド 197 の Red Hat プラットフォーム向けに作成されています。 IRIS のバイナリファイル名は、 ISCAgent-2020.1.0.215.0-lnxrhx64.tar.gz および IRISHealth-2020.1.0.217.1-lnxrhx64.tar.gz形式で書かれています。 InterSystems IRIS のライセンスキーは、既存のライセンスキー (iris.key) を使用いただけるはずです。 また、InterSystems IRIS Evaluation Service (https://download.intersystems.com/download/register.csp) より評価キーをリクエストしていただくこともできます。
セットアップ済みの AWS アカウントが必要です。 お持ちでない方は、 https://aws.amazon.com/getting-started/ よりセットアップしてください。
IAM (ユーザーまたはロール) を作成します。 IAM ユーザーは、AWS CloudFormation のアクションを許可するポリシーが必要です。 CloudFormation テンプレートをデプロイするのに、ルートアカウントは使わないでください。 AWS CloudFormation のアクションに加え、スタックを作成または削除する IAM ユーザーは、スタックテンプレートに依拠する別のアクセス権限も必要になります。 このデプロイでは、次のセクションで紹介するすべてのサービスへのアクセス権が必要になります。参考資料: https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-iam-template.html
CloudFormation テンプレートは、EC2 インスタンスが S3 バケットにアクセスし、CloudWatch にログを入力するのを許可する IAM ロールが必要です。 そうようなロールに関連するポリシーの例については、「IAM Policy for EC2 instance」と題した付録をご参照ください。参考資料: https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html
「my bucket」という名前の S3 バケットを作成し、IRIS のバイナリファイルと iris.key をコピーします。
BUCKET=
aws s3 mb s3://$BUCKET
aws s3 cp ISCAgent-2020.1.0.215.0-lnxrhx64.tar.gz s3://$BUCKET
aws s3 cp IRISHealth-2020.1.0.217.1-lnxrhx64.tar.gz s3://$BUCKET
aws s3 cp iris.key s3://$BUCKET
テンプレートは、IRIS を既存の VPC とサブネットにデプロイするようにデザインされています。 AZ が 3 つ以上あるリージョンでは、3 つの異なる AZ でプライベートサブネットを 3 つ作成することを推奨しています。 Bastion Host は、VPC 内にあるパブリックサブネットのいずれかに配置します。 CloudFormation テンプレート (https://docs.aws.amazon.com/codebuild/latest/userguide/cloudformation-vpc-template.html) を基に VPC とサブネットを作成するには、AWS の例に従ってください。
このテンプレートによってプロビジョンされる EC2 インスタンスにアクセスするには、EC2 キーペアが少なくとも 1 つは必要です。 詳細は、こちらのガイドをご参照ください: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html。
以下の AWS サービスに関する知識が必要になります。
このデプロイを実行するにあたり、アカウント制限の引き上げは必要ありません。
適切なポリシーやアクセス権限の詳細は、こちらでご確認くださいhttps://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-iam-template.html。
注意: AWS アソシエイト認定をお持ちのユーザーなら、十分な知識を修得していると思われます。
このセクションでは、考えられる 2 つのパターンのデプロイを対象としたアーキテクチャダイアグラムをご紹介し、アーキテクチャデザインの選択肢についても解説します。
優先されるこのオプションでは、高い可用性と耐障害性を確保するために、IRIS のミラー化されたインスタンスが 2 つのアベイラビリティーゾーンでロードバランサーの後に置かれます。 アベイラビリティーゾーンが 3 以上あるリージョンでは、Arbiter ノードが 3 つ目の AZ に置かれます。
データベースノードは、プライベートサブネットに置かれます。 Bastion Host は、同じ VPC 内のパブリックサブネットにあります。
InterSystems IRIS は、開発や評価を行う目的で、1 つのアベイラビリティーゾーンにデプロイすることもできます。 データフローやアーキテクチャのコンポーネントは、前のセクションで説明したものと同じです。 このソリューションは、高い可用性も、耐障害性も提供しないため、プロダクションでの使用には適していません。
このセクションでは、このガイドを実行してデプロイされる InterSystems IRIS のデフォルト設定、ベストプラクティスの概要、AWS でソリューションをセキュリティ保護するオプションについて解説します。
InterSystems IRIS の EC2 インスタンスは、プライベートサブネットに配置し、それへのアクセスは Bastion Host を経由する場合か、ロードバランサーを経由するアプリケーションに限定する必要があります。
InterSystems IRIS を実行するデータベースインスタンスでは、保存データは基になる (かつ暗号化されている) EBS ボリューム内に格納されます。 この CloudFormation テンプレートは、アカウントのデフォルトの AWS マネージドキーで暗号化される「aws/eb」という名前の EBS ボリュームを作成します。
この CloudFormation では、クライアントとサーバー間の接続と、インスタンス間の接続はセキュリティ保護されません。 転送中のデータを暗号化する必要がある場合は、デプロイが完了してから、以下のリンクに記載されているステップを実行してください。
SuperServer 接続 (JDBC/ODBC の接続) で SSL を有効化するステップ: https://docs.intersystems.com/irislatestj/csp/docbook/Doc.View.cls?KEY=GCAS_ssltls#GCAS_ssltls_superserver
IRIS EC2 インスタンス間では、耐久性を備えたマルチ AZ 構成のトラフィックも暗号化が必要になる場合があります。 これは、ミラー化に対し SSL 暗号化を有効にする (https://docs.intersystems.com/irislatestj/csp/docbook/Doc.View.cls?KEY=GCAS_ssltls#GCAS_ssltls_mirroring) か、インスタンス間のトラフィックを自動的に暗号化する、インスタンスの r5n ファミリーに切り替えることで実現できます。
AWS Certificate Manager (ACM) を使用すれば、Secure Sockets Layer/Transport Layer Security (SSL/TLS) 証明書のプロビジョン、管理、デプロイを簡単に行えます。
デフォルトで、IRIS Management Portal は、Bastion Host 経由でのみアクセスできるようになっています。
InterSystems IRIS は、messages.log ファイルにログ情報を保管します。 CloudFormation では、追加のログ / モニタリングサービスはセットアップされません。 こちらに記載される構造化ログを有効化することを推奨します。https://docs.intersystems.com/irislatestj/csp/docbook/Doc.View.cls?KEY=ALOG
CloudFormation テンプレートは、InterSystems IRIS と CloudWatch の連携をインストールしません。 InterSystems では、https://github.com/antonum/CloudWatch-IRIS の InterSystems IRIS と CloudWatch の連携を推奨しています。 これにより、IRIS のメトリクスとログが messages.log ファイルから AWS CloudWatch に収集されます。
CloudFormation テンプレートは、AWS CloudTrail のログを有効化しません。 CloudTrail のログを有効化するには、CloudTrail のサービスコンソールに移動し、CloudTrail のログを有効化します。 CloudTrail を使用すると、AWS インフラストラクチャで実行されるアクションに関連するアクティビティは、イベントとして CloudTrail に記録されます。 これにより、AWS アカウントのガバナンス、コンプライアンス、運用、リスクの監査を有効化できます。
参考資料: https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html
InterSystems では、InterSystems IRIS のログとメトリクスのモニタリング、および少なくとも以下のインジケーターに対しアラートを設定することを推奨しています。
上の内容に加え、ユーザーの皆さまには独自のモニタリングメトリクス、アラートメトリクス、アプリケーション固有の KPI を指定することを推奨しています。
このセクションでは、本ガイドの「デプロイアセット」のセクションで説明する AWS のリソースを作成します。 このデプロイの実行中に使用される AWS サービスのコストはお客様の負担となります。 InterSystems IRIS のデプロイに最低限必要な設定をするだけでも、高い可視性とセキュリティが確保されます。
本ガイドのテンプレートでは、InterSystems IRIS の BYOL (Bring Your Own License「ライセンスは各自で用意する」) ライセンスモデルを採用しています。
InterSystems IRIS Marketplace のページでは、Pay Per Hour IRIS Pricing (時間課金制の IRIS 使用料金) についてご説明しています: https://aws.amazon.com/marketplace/pp/B07XRX7G6B?qid=1580742435148&sr=0-3
BYOL モデルの料金に関する詳細は、https://www.intersystems.com/who-we-are/contact-us/ より InterSystems までお問い合わせください。
正常に機能するプラットフォームを提供するには、以下の AWS アセットが必要です。
次のテーブルでは、デプロイ用の CloudFormation テンプレートに組み込まれる EC2 と EBS のキャパシティおよび AWS リソースのコスト (単位: $/月) に関する推奨事項を示しています。
| ワークロード | ||||
| EC2 DB* | ||||
| EC2 Arbiter* | ||||
| EC2 Bastion* | ||||
| EBS SYS | ||||
| EBS DB | ||||
| EBS JRN | ||||
| 計算コスト | ||||
| EBS ボリュームのコスト | ||||
| EBS IOPS コスト | ||||
| サポート (ベーシック) | ||||
| コスト合計 | ||||
| 計算リンク | ||||
*すべての EC2 インスタンスには追加で gp2 の EBS ルートボリュームが 20GB 含まれます。
AWS の推定コストは、バージニア州北部の地域のオンデマンド料金を基に計算されています。 スナップショットとデータ転送のコストは含まれていません。 料金に関する最新情報は、AWS 料金を参照してください。
InterSystems IRIS CloudFormation テンプレートには、デプロイオプションが 2 つあります。 マルチ AZ 配置オプションは、プロダクションのワークロードに適した、可用性が高く、冗長性を備えたアーキテクチャを提供します。 シングル AZ 配置オプションは、低コストのオプションで、開発やテストのワークロードに適しています。
InterSystems IRIS のデプロイメントは、CloudFormation テンプレートを使って実行されます。同テンプレートは、入力パラメータを受け取り、それをネストされた適切なテンプレートに渡します。 それらは、条件や依存関係に従って順番に実行されます。
作成される AWS リソース
AWS 全般
S3
ネットワーク
データベース
スタックの作成マスターテンプレートの出力は、JDBC クライアントを InterSystems IRIS に接続する際に使用できる JDBC エンドポイント、Bastion Host のパブリック IP、および両方の IRIS ノードのプライベート IP、と 4 つの出力があります。
Node 01/02 Management Portal へのリンクをクリックします。 ユーザー名「SuperUser」および CloudFormation テンプレートで選択したパスワードを使ってログインします。
System Administration -> Configuration -> Mirror Settings -> Edit Mirror と順に移動します。 システムに 2 つのファイルオーバーメンバが設定されていることを確認します。
ミラー化されたデータベースが作成され、アクティブであることを確認します。 System Administration -> Configuration -> Local Databases と順に移動します。
「First Look JDBC」と題したドキュメント (https://docs.intersystems.com/irislatestj/csp/docbook/DocBook.UI.Page.cls?KEY=AFL_jdbc) の内容に従って、JDBC が Load Balancer を介して IRIS に接続されていることを確認します。 URL 変数をテンプレートの出力に表示されている値に変更し、パスワードも「SYS」からセットアップの最中に選択したパスワードに変更します。
Node02 で、Management Portal にアクセス (上の「正常性チェック」のセクション参照) し、Configuration->Edit Mirror と順に開きます。 ページの一番下に「このメンバはバックアップです。 プライマリに変更を加える必要があります。」 というメッセージが表示されます。
AWS EC2 マネジメントダッシュボードで Node01 インスタンスを見つけます。 その名前は、MyStackName-Node01-1NGXXXXXX の形式で書かれています。
Node01 インスタンスを再起動します。 これにより、インスタンス / AZ の停止がシミュレートされます。
Node02 の「Edit Mirror」ページを再度読み込みます。 するとステータスは、このメンバはプライマリです。 変更内容は他のメンバに送信されます。 に変わるはずです。
CloudFormation をデプロイしても、InterSystems IRIS のバックアップは有効化されません。 当社では、EBS Snapshot (https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSSnapshots.html) と IRIS Write Daemon Freeze (https://docs.intersystems.com/irislatestj/csp/docbook/Doc.View.cls?KEY=GCDI_backup#GCDI_backup_methods_ext) の両方を使って IRIS EBS ボリュームをバックアップすることを推奨しています。
異常な IRIS インスタンスは、IRIS のミラーリング機能と Load Balancer により検出され、トラフィックは別のミラーノードに移動されます。 回復可能なインスタンスはミラーに再度参加して、通常の操作が続行されます。 異常な状態が続くインスタンスがある場合は、当社のナレッジベースおよび本ガイドの「緊急メンテナンス」のセクションをご覧ください。
AZ の障害が発生すると、トラフィックが一時的に中断される場合があります。 インスタンスの障害発生時と同様に、この場合も IRIS のミラーリング機能と Load Balancer がトラフィックを使用可能な別の AZ に切り替えて状況に対処します。
本ガイドで紹介するアーキテクチャでは、マルチリージョンオペレーションをサポートする設定はデプロイされません。 IRIS の非同期ミラーリングと AWS Route53 を使用すれば、中断を最小限に抑えながらリージョンの障害に対処できる構成を作成できます。 詳細は、https://community.intersystems.com/post/intersystems-iris-example-reference-architectures-amazon-web-services-awsを参照してください。
IRIS ジャーナルとデータベースの EBS ボリュームは、容量が上限に達する場合があります。 InterSystems では、IRIS Dashboard ならびに「df」のような Linux のファイルシステムツールを使い、ジャーナルとデータベースのボリュームの状態をモニタリングすることを推奨しています。
ジャーナルとデータベースのボリュームは、EBS ガイド https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-modify-volume.htmlを使えば拡張することができます。 注意: EBS ボリュームの拡張と Linux ファイルシステムの拡張の両方のステップを実行する必要があります。 また、データベースのバックアップを実行した後に、Purge Journalsを実行すれば、ジャーナルが占めていた領域を開放することもできます。
また、インスタンスに対して CloudWatch Agent を有効にして (この CloudFormation テンプレートでは無効)、ディスク領域をモニタリングすることも検討してもよいでしょう (https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Install-CloudWatch-Agent.html)。
AWS Certificate Manager (ACM) を使えば、Secure Sockets Layer/Transport Layer Security (SSL/TLS) 証明書を簡単にプロビジョン、デプロイ、管理し、またその有効期限をモニタリングできます。
証明書の有効期限は把握しておく必要があります。 InterSystems では、証明書の有効期限をモニタリングする統合プロセスは提供していません。 AWS では、アラームのセットアップに便利な CloudFormation テンプレートが提供されています。 詳細は、こちらのリンク https://docs.aws.amazon.com/config/latest/developerguide/acm-certificate-expiration-check.html をご覧ください。
ミラー化された構成において IRIS をアップグレードする手順については、https://docs.intersystems.com/irislatestj/csp/docbook/Doc.View.cls?KEY=GCI_upgrade#GCI_upgrade_tasks_mirrorsを参照してください。
継続的なタスクについて、InterSystems では以下を含む AWS と InterSystems のベストプラクティスを実施することを推奨しています。
また、EC2 インスタンスに CloudWatch Agent を追加することを検討しても良いでしょう: https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Install-CloudWatch-Agent.html。
EC2 インスタンスを使用できる場合は、Bastion Host 経由でインスタンスに接続しましょう。
注意: インスタンスを停止 / 開始した後は、Bastion Host のパブリック IP が変更される場合があります。 これが、IRIS クラスタの可用性や JDBC 接続に影響することはありません。
コマンドラインを使ってアクセスするには、以下のコマンドを使って Bastion Host 経由で IRIS ノードに接続します。
$ chmod 400
$ ssh -J ec2-user@<bastion-public-ip> ec2-user@<node-private-ip> -L 52773:1
上のコマンドを実行したら、インスタンスの Management Portal が http://localhost:52773/csp/sys/%25CSP.Portal.Home.zen にて使用可能になります。ユーザは「SuperUser」、パスワードはスタックの作成時に入力したパスワードを使います。
IRIS のコマンドプロンプトにアクセスするには、以下のコマンドを使います。
$ iris session iris
「InterSystems IRIS Management and Monitoring」ガイドを参照してください: https://docs.intersystems.com/irislatestj/csp/docbook/DocBook.UI.Page.cls?KEY=GCM
InterSystems サポートへの問い合わせ。
EC2 インスタンスが使用またはアクセスできない場合は、AWS サポートまでお問い合わせください。
注意: マルチ AZ 配置のデプロイで発生する AZ やインスタンスの障害は、自動的に処理されます。
CloudFormation で「Create Stack」(スタックを作成) を実行できません「Create Stack」を実行できる適切な権限を持っていることをご確認ください。 AWS アカウントの管理者にアクセス権限をお求めください。また、問題が解決しない場合は AWS サポートまでお問い合わせください
スタックは作成されますが、IRIS にアクセスできませんEC2 インスタンスのステータスが「CEATE COMPLETED」に変わってから、IRIS の使用準備が完全に整うまでは、およそ 2 分程度かかります。 SSH で EC2 Node のインスタンスと通信し、IRIS が稼働していることをご確認ください。
$iris list
アクティブな IRIS インスタンスが見当たらない場合や、“iris: command not found” というメッセージが表示される場合は、IRIS のインストールが失敗したことを意味します。 インスタンスを最初に開始するときに、インスタンスの $cat /var/log/cloud-init-output.log をチェックして、インストールに問題がなかったどうかを確認します。
IRIS は稼働していますが、Management Portal にアクセスすることも、[Java] アプリケーションから接続することもできませんCloudFormation が作成した Security Group に、お使いのソース IP アドレスが許可されている IP アドレスとして表示されていることをご確認ください。
InterSystems Worldwide Response Center (WRC) では、専門家によるテクニカルサポートを提供しています。
InterSystems IRIS のサポートは、常に IRIS へのサブスクリプションに含まれています。
電話、メール、オンラインでのサポートは、24 時間、年中無休でご利用いただけます。 世界 15 か国にサポートアドバイザーを配置。英語、スペイン語、ポルトガル語、イタリア語、ウェールズ語、アラビア語、ヒンディー語、中国語、タイ語、スウェーデン語、韓国語、日本語、フィンランド語、ロシア語、フランス語、ドイツ語、ヘブライ語およびハンガリー語での対応が可能です。 お客様の成功を大切にする、経験、知識ともに豊富なサポートスペシャリストが、すべてのお客様を素早くサポートいたします。
すぐにサポートが必要な場合
電話サポート:+1-617-621-0700 (US)+44 (0) 844 854 2917 (UK)0800615658 (NZ フリーダイヤル)1800 628 181 (AUS フリーダイヤル)
メールサポート:support@intersystems.com
オンラインサポート:WRC ダイレクトsupport@intersystems.com までログイン情報をお求めください。
以下の IAM ポリシーを使うことで、EC2 インスタンスは S3 バケット ‘my-bucket’ からオブジェクトを読み取り、CloudWatch にログを書き込むことができます。
{ "Version": "2012-10-17", "Statement": [ { "Sid": "S3BucketReadOnly", "Effect": "Allow", "Action": ["s3:GetObject"], "Resource": "arn:aws:s3:::my-bucket/" }, { "Sid": "CloudWatchWriteLogs", "Effect": "Allow", "Action": [ "logs:CreateLogGroup", "logs:CreateLogStream", "logs:PutLogEvents", "logs:DescribeLogStreams" ], "Resource": "arn:aws:logs:::" } ]}
InterSystems は自社が提供する InterSystems IRIS の Dockerイメージについて、Linux 環境での使用のみをサポートしています。 Docker for Windows は Linux プラットフォームのようにコンテナをネイティブプロセスとして実行するのではなく、Windows の仮想化機能である Hyper-V で実行される Linux VM を作成してコンテナをホストします。 このような追加レイヤーによって複雑度が増しているため、InterSystems は現時点で Docker for Windows をサポートすることができません。
ただし、テストやその他の特殊な目的のために InterSystems の IRIS ベースのコンテナを Docker for Windows 環境で実行する必要があることは私たちも理解しています。 この記事では、InterSystems が提供するコンテナイメージの使用に関して InterSystems が認識している Docker for Windows と Docker for Linux の違いについて説明します。 その他にも予期しない問題が発生する可能性はあります。 Windows プラットフォームで InterSystems IRIS のイメージとコンテナを使用する場合は、参考のために Docker ドキュメント（特に「Getting started with Docker for Windows」）にアクセスできることを確認してください。
Docker for Windows 環境のコンテナで外部永続ストレージを操作する場合は、Windows および Linux のファイルシステムとファイル操作の両方が関係してくるため、ここでは主にストレージに関係する違いを説明しています。
InterSystems が提供するイメージを使用して InterSystems IRIS を Docker コンテナで実行する場合の一般的な情報については、「Running InterSystems IRIS in Docker Containers」と「First Look: InterSystems IRIS in Docker Containers」を参照してください。
Windows では Docker が存在するディスクドライブを共有し、Docker に操作対象となるすべてのストレージへのアクセスを許可する必要があります。 1 台以上のドライブを共有するには、次の手順に従ってください（この手順は前の項目の手順と組み合わせることができます）。
Docker を使用する場合は、一般的には外部ファイルシステム内のディレクトリをコンテナ内のボリュームとしてマウントし、それをコンテナ内のソフトウェアが必要とするすべての外部ファイル用の場所として使用するのが便利です。 例えば、あるボリュームをマウントし、iris-main プログラムの --key オプションとパスワード変更スクリプトがそれぞれアクセスする外部ディレクトリにある InterSystems IRIS のライセンスキー（iris.key）や所定の InterSystems IRIS のパスワードを含むファイルを配置できます（「Running InterSystems IRIS in Containers」の「The iris-main Program」と「Changing the InterSystems IRIS Password」を参照してください）。 ただし、Docker for Windowsではファイル操作とアクセス許可の違いにより、マウントされた外部ボリューム上のファイルがコンテナ内のプログラムによって適切に使用されない場合があります。 多くの場合はプログラムでコンテナ内のファイルをコピーしてからそのコピーを使用することで、アクセス許可の問題を解決できます。
例えば、**iris-main --before **オプションはコンテナ内の InterSystems IRIS インスタンスのパスワードを変更するためによく使用されます。以下に例を示します。
--before "changePassword.sh /external/password.txt"
この方法を使っても Windows で意図したとおりにパスワードを変更できない場合は、以下を試してください。
--before "cp /external/password.txt /external/password_copied.txt && \
changePassword.sh /external/password_copied.txt"
動的に変更されるファイルが多数存在する場合、個別にマウントしてすべてのファイルをコピーできたとしても、コンテナ内に Windows ファイルシステムを直接マウントすると問題が発生する可能性があります。 InterSystems IRIS の場合、これは特にインスタンス固有データを永続的に保管するための Durable %SYS 機能（「Running InterSystems IRIS in Containers」の「Durable %SYS for Persistent Instance Data」を参照してください）とジャーナルファイルの保管の両方に当てはまります。 この問題は名前付きボリュームをマウントすることで解決できます。名前付きボリュームは、システム上のコンテナをホストしている Linux VM のファイルシステムにマウントポイントを持つストレージボリュームです。 VM はファイルシステムベースであるため、このようなボリュームの内容は Docker やシステムがダウンした場合でも VM の他の部分と一緒に Windows ディスクに保存されます。
例えば InterSystems IRIS コンテナを実行中に Durable %SYS を有効化する場合、一般的には外部ボリュームをマウントし、--env オプションを使用して ISC_DATA_DIRECTORY 環境変数をそのボリュームの場所に設定します。以下に例を示します。
docker run ... \
--volume /nethome/pmartinez/iris_external:/external \
--env ISC_DATA_DIRECTORY=/external/durable/
この方法は Docker for Windows では使えません。代わりに、docker volume create コマンドで名前付きボリュームを作成し、Durable %SYS ディレクトリをそこに配置する必要があります。 また、Linux とは異なり、ISC_DATA_DIRECTORY には最上位の Durable %SYS ディレクトリである /irissys を指定する必要があります。 したがって、Windows では次のようなオプションになります。
docker volume create durable
docker run ... \
--volume durable:/durable \
--env ISC_DATA_DIRECTORY=/durable/irissys/
インスタンスのジャーナルファイルにこの方法を使用するには、上記の Durable %SYS の例と同じように名前付きボリュームを作成してマウントし、任意の構成方法（^JOURNAL ルーチン、管理ポータルの [Journal Settings] ページ、または iris.cpf ファイル）を使用して現在および代替のジャーナルディレクトリを名前付きボリュームの場所に設定します。 現在のジャーナルディレクトリと代替のジャーナルディレクトリを分離するには、それぞれに対応する名前付きボリュームを作成してマウントする必要があります （この方法は_十分に検証されておらず_、ジャーナルファイルが危険にさらされる可能性がありますのでご注意ください）。
VM 内の名前付きボリュームにある Linux ファイルシステムのマウントポイントを検出するには、次のように docker volume inspect コマンドを使用します。
docker volume inspect durable_data
[
{
"CreatedAt": "2018-05-04T12:11:54Z",
"Driver": "local",
"Labels": null,
"Mountpoint": "/var/lib/docker/volumes/durable_data/_data",
"Name": "durable_data",
"Options": null,
"Scope": "local"
}
]
上記の内容をすべて考慮し、「First Look: InterSystems IRIS in Docker Containers」の「Run and Investigate the InterSystems IRIS-based Container」に記載されている Linux プラットフォームでの実行を想定した最終的な docker run コマンドと Docker for Windows を使用した同等の docker run コマンドを比較すると次のようになります。
$ docker run --name iris3 --detach --publish 52773:52773 \
--volume /nethome/pmartinez/iris_external:/external \
--env ISC_DATA_DIRECTORY=/external/durable \
--env ICM_SENTINEL_DIR=/external iris3:test --key /external/iris.key \
--before "changePassword.sh /external/password.txt"
C:\Users\pmartinez>docker volume create durable
C:\Users\pmartinez>docker volume create journals
C:\Users\pmartinez>docker run --name iris3 --detach --publish 52773:52773 \
--volume durable:/durable\
--volume journals:/journals
--env ISC_DATA_DIRECTORY=/durable/irissys \
--env ICM_SENTINEL_DIR=/durable iris3:test --key /external/iris.key \
--before "cp /external/password.txt /external/password_copied.txt && \
changePassword.sh /durable/password_copied.txt"
Docker for Windows での InterSystems 提供コンテナの使用に関する情報をご提供可能な方は、こちらにコメントを追加するか、記事の投稿をお願いします！
インスタンスのデータに基づくビジネスインテリジェンスを実装しようと計画中です。 DeepSee を使うには、データベースと環境をどのようにセットアップするのがベストですか？
このチュートリアルでは、DeepSee の 3 つのアーキテクチャ例を示しながら、上記の質問を解決します。 基本的なアーキテクチャモデルを、その制限を重点に説明するところから始めましょう。 以降のモデルは、複雑さが中程度のビジネスインテリジェンスアプリケーションに推奨されており、ほとんどのユースケースで十分なはずです。 チュートリアルの最後には、高度な実装を管理できるように、アーキテクチャの柔軟性を強化する方法を説明します。
このチュートリアルに含まれる例では、新しいデータベースとグローバルマッピングを紹介し、それらをセットアップする理由とタイミングについて説明します。 アーキテクチャを構築する際には、より柔軟な例から得られるメリットについて説明します。
データの高可用性を実現する場合、InterSystems では一般的にミラーリングとシャドウイングを使用して、ミラー/シャドウサーバーに DeepSee を実装することをお勧めしています。 データの元のコピーをホストするマシンを「プライマリサーバー」と呼び、データとビジネスインテリジェンスアプリケーションのコピーをホストするマシンを「分析（またはレポーティング）サーバー」と呼びます。
プライマリサーバーと分析サーバーを用意しておくことは非常に重要です。これは主に、いずれのサーバーにおいてもパフォーマンスに関する問題を回避するためです。 推奨アーキテクチャに関するドキュメントをご覧ください。
ソースデータとコードを同じデータベースに保存することは、通常、規模の小さなアプリケーションでのみうまく機能します。 より大規模なアプリケーションでは、ソースデータとコードをそれぞれの専用データベースに保存することが推奨されます。専用のデータベースを使用することで、データを分離しながらも、DeepSee が実行するすべてのネームスペースでコードを共有することができます。 ソースデータ用のデータベースは、本番サーバーからミラーリングできるようにしておく必要があります。 このデータベースは、読み取り専用または読み取り/書き込みのいずれかです。 このデータベースでは、ジャーナリングを有効にしておくことをお勧めします。
ソースクラスとカスタムアプリケーションは、本番サーバーと分析サーバーの両方にある専用データベースに保存します。 これら 2 つのソースコード用データベースは同期している必要がなく、同じバージョンの Caché を実行している必要もありません。 コードが別の場所で定期的にバックアップされているのであれば、ジャーナリングは通常必要ではありません。
このチュートリアルでは、次の構成を使用しています。 分析サーバーの APP ネームスペースには、デフォルトのデータベースとして APP-DATA と APP-CODE があります。 APP-DATA データベースは、プライマリサーバーにある ソースデータ用データベースのデータ（ソーステーブルのクラスとファクト）にアクセスできます。 APP-CODE データベースは、Caché コード（.cls と .INT ファイル）とほかのカスタムコードを保存します。 このようにデータとコードを分離するのは典型的なアーキテクチャであり、ユーザーは、DeepSee コードとカスタムアプリケーションを効率的にデプロイすることができます。
DeepSee を使用したビジネスインテリジェンス実装は、異なるネームスペースから実行されることがよくあります。 この記事では単一の APP ネームスペースのセットアップ方法を示しますが、同じ手順を使えば、ビジネスインテリジェンスアプリケーションが実行するすべてのネームスペースをセットアップすることも可能です。
ドキュメントに含まれる初回セットアップの実行に関するページの内容を理解しておくことをお勧めします。 このページには、Web アプリケーションのセットアップ、DeepSee グローバルを個別のデータベースに配置する方法、および DeepSee グローバルの代替マッピングのリストが含まれています。
このシリーズの第 2 部では、基本的なアーキテクチャモデルの実装について説明します。
この記事では、スナップショットを使用したソリューションとの統合の例を使って、_外部バックアップ_による Caché のバックアップ方法を紹介します。 このところ私が目にするソリューションの大半は、Linux の VMware にデプロイされているため、この記事の大半では、例として、ソリューションが VMware スナップショットテクノロジーをどのように統合しているかを説明しています。
Caché をインストールすると、Caché データベースを中断せずにバックアップできる Caché オンラインバックアップが含まれています。 しかし、システムがスケールアップするにつれ、より効率的なバックアップソリューションを検討する必要があります。 Caché データベースを含み、システムをバックアップするには、スナップショットテクノロジーに統合された_外部バックアップ_をお勧めします。
詳しい内容は外部バックアップのオンラインドキュメンテーションに説明されていますが、 主な考慮事項は次のとおりです。
「スナップショットの整合性を確保するために、スナップショットが作成される間、Caché はデータベースへの書き込みをfreezeする方法を提供しています。 スナップショットの作成中は、データベースファイルへの物理的な書き込みのみがfreezeされるため、ユーザーは中断されることなくメモリ内で更新を実行し続けることができます。」
また、仮想化されたシステム上でのスナップショットプロセスの一部によって、バックアップされている VM にスタンタイムと呼ばれる短い無応答状態が発生することにも注意してください。 通常は 1 秒未満であるため、ユーザーが気付いたり、システムの動作に影響を与えたりすることはありませんが、状況によってはこの無応答状態が長引くことがあります。 無応答状態が Caché データベースミラーリングの QoS タイムアウトより長引く場合、バックアップノードはプライマリに障害が発生したとみなし、フェイルオーバーします。 この記事の後の方で、ミラーリング QoS タイムアウトを変更する必要がある場合に、スタンタイムをどのように確認できるかについて説明します。
この記事では、Caché オンラインドキュメンテーション『Backup and Restore Guide（バックアップと復元ガイド）』も確認する必要があります。
ほかのソリューションがない場合は、ダウンタイム無しでバックアップを行えるこのソリューションが InterSystems データプラットフォームに同梱されています。 _Caché オンラインバックアップ_は、Caché データベースファイルのみをバックアップするもので、データに割り当てられたデータベースのすべてのブロックをキャプチャし、出力をシーケンシャルファイルに書き込みます。 Caché Online Backup は累積バックアップと増分バックアップをサポートしています。
VMware の文脈では、Caché Online Backup はゲスト内で発生するバックアップソリューションです。 ほかのゲスト内ソリューションと同様に、Caché Online Backup の動作は、アプリケーションが仮想化されていようが、ホストで直接実行していようが、基本的に変わりません。 Caché Online Backup は、システムバックアップと連携しながら Caché のオンラインバックアップ出力ファイルを、アプリケーションが使用しているその他すべてのファイルシステムとともに、バックアップメディアにコピーします。 最小限のシステムバックアップには、インストールディレクトリ、ジャーナルおよび代替ジャーナルディレクトリ、アプリケーションファイル、およびアプリケーションが使用する外部ファイルを含むすべてのディレクトリを含める必要があります。
Caché Online Backup は、Caché データベースやアドホックバックアップのみをバックアップする低コストのソリューションを実装したいと考えている小規模サイト向けのエントリレベルのアプローチとして捉えてください。ミラーリングをセットアップする際のバックアップなどに役立てられます。 しかし、データベースのサイズが増加したり、Caché が顧客のデータランドスケープの一部でしかない場合は、_外部バックアップ_にスナップショットテクノロジーとサードパーティ製ユーティリティを合わせたソリューションがベストプラクティスとして推奨されます。非データベースファイルのバックアップ、より高速な復旧時間、エンタープライズ全体のデータビュー、より優れたカタログと管理用ツールなど、さまざまなメリットが得られます。
VMware を例として使用します。VMware で仮想化すると、VM 全体を保護するための追加機能と選択肢が追加されます。 ソリューションの仮想化が完了した時点で、オペレーティングシステム、アプリケーション、データを含むシステムを .vmdk（とその他の）ファイル内に効果的にカプセル化したことになります。 これらのファイルの管理は非常に簡単で、必要となった場合にはシステム全体の復旧に使用できるため、オペレーティングシステム、ドライバ、サードパーティ製アプリケーション、データベースとデータベースファイルなどのコンポーネントを個別に復旧して構成する必要のある物理システムで同じような状況が発生した場合とは大きく異なります。
VMware の vSphere Data Protection（VDP）や、Veeam や Commvault などのサードパーティ製バックアップソリューションでは、VMware 仮想マシンスナップショットを使用してバックアップを作成しています。 VMware スナップショットの概要を説明しますが、詳細については、VMware ドキュメンテーションを参照してください。
スナップショットは VM 全体に適用されるものであり、オペレーティングシステムとすべてのアプリケーションまたはデータベースエンジンはスナップショットが発生していることを認識しないということに注意してください。 また、次のことにも注意してください。
VMware スナップショット自体はバックアップではありません！
スナップショットは、バックアップソフトウェアによるバックアップの作成を_可能にします_が、スナップショット自体はバックアップではありません。
VDP とサードパーティ製バックアップソリューションは、バックアップアプリケーションとともに VMware スナップショットプロセスを使用して、スナップショットの作成と、非常に重要となるその削除を管理します。 おおまかに見ると、VMware スナップショットを使用した外部バックアップのイベントのプロセスと順序は次のとおりです。
バックアップソリューションは、変更ブロック追跡（CBT）などのほかの機能も使用し、増分または累積バックアップを可能にして速度と効率性（容量節約において特に重要）を実現します。また、一般的に、データの重複解除や圧縮、スケジューリング、整合性チェックなどで IP アドレスが更新された VM のマウント、VM とファイルレベルの完全復元、およびカタログ管理などの重要な機能性も追加します。
適切に管理されていない、または長期間実行されたままの VMware スナップショットは、ストレージを過剰に消費し（データの変更量が増えるにつれ、差分ファイルが増加し続けるため）、VM の速度を低下させてしまう可能性があります。
本番インスタンスで手動スナップショットを実行する前に、十分に検討する必要があります。 なぜ実行しようとしているのか、 スナップショットが作成された時間に戻すとどうなるか、 作成とロールバック間のすべてのアプリケーショントランザクションはどうなるか、といったことを検討してください。
バックアップソフトウェアがスナップショットを作成し、削除しても問題ありません。 スナップショットの存続期間は、短期間であるものなのです。 また、バックアップ戦略においては、ユーザーやパフォーマンスへの影響をさらに最小限に抑えられるように、システムの使用率が低い時間を選ぶことも重要です。
スナップショットを作成する前に、保留中のすべての書き込みがコミットされ、データベースが一貫した状態になるように データベースを静止させる必要があります。 Caché は、スナップショットが作成される間、データベースへの書き込みをコミットして短時間フリーズ（停止）するメソッドと API を提供しています。 こうすることで、スナップショットの作成中は、データベースファイルへの物理的な書き込みのみがフリーズされるため、ユーザーは中断されることなくメモリ内で更新を実行し続けることができます。 スナップショットがトリガーされると、データベースの書き込みが再開し、バックアップはバックアップメディアへのデータのコピーを続行します。 フリーズからの復旧は、非常に短時間（数秒）で発生します。
書き込みを一時停止するのに加え、Caché Freeze は、ジャーナルファイルの切り替えとジャーナルへのバックアップマーカーの書き込みも処理します。 ジャーナルファイルは、物理データベースの書き込みがフリーズしている間、通常通りに書き込みを続けます。 物理データベースの書き込みがフリーズしている間にシステムがクラッシュした場合、データは、起動時に、通常通りジャーナルから復元されます。
以下の図は、整合性のあるデータベースイメージを使用してバックアップを作成するための、VMware スナップショットを使用した Freeze と Thaw の手順を示しています。
Freeze から Thaw の時間が短いところに注目してください。読み取り専用の親をバックアップターゲットにコピーする時間でなく、スナップショットを作成する時間のみです。
vSphere では、スナップショット作成のいずれか側で自動的にスクリプトを呼び出すことができ、この時に、Caché Freeze と Thaw が呼び出されます。 注意: この機能が正しく機能するために、ESXi ホストは _VMware ツール_を介してゲストオペレーティングシステムにディスクを静止するように要求します。
VMware ツールは、ゲストオペレーティングシステムにインストールされている必要があります。
スクリプトは、厳密な命名規則と場所のルールに準じる必要があります。 ファイルの権限も設定されていなければなりません。 以下は、Linux の VMware の場合のスクリプト名です。
# /usr/sbin/pre-freeze-script
# /usr/sbin/post-thaw-script
以下は、InterSystems のチームが内部テストラボインスタンスに対して、Veeam バックアップで使用する Freeze と Thaw のスクリプト例ですが、ほかのソリューションでも動作するはずです。 これらの例は、vSphere 6 と Red Hat 7 で検証され、使用されています。
これらのスクリプトは例として使用でき、方法を示すものではありますが、各自の環境で必ず検証してください！
#!/bin/sh
#
# Script called by VMWare immediately prior to snapshot for backup.
# Tested on Red Hat 7.2
#
LOGDIR=/var/log
SNAPLOG=$LOGDIR/snapshot.log
echo >> $SNAPLOG
echo "`date`: Pre freeze script started" >> $SNAPLOG
exit_code=0
# Only for running instances
for INST in `ccontrol qall 2>/dev/null | tail -n +3 | grep '^up' | cut -c5- | awk '{print $1}'`; do
echo "`date`: Attempting to freeze $INST" >> $SNAPLOG
# Detailed instances specific log
LOGFILE=$LOGDIR/$INST-pre_post.log
# Freeze
csession $INST -U '%SYS' "##Class(Backup.General).ExternalFreeze(\"$LOGFILE\",,,,,,1800)" >> $SNAPLOG $
status=$?
case $status in
5) echo "`date`: $INST IS FROZEN" >> $SNAPLOG
;;
3) echo "`date`: $INST FREEZE FAILED" >> $SNAPLOG
logger -p user.err "freeze of $INST failed"
exit_code=1
;;
*) echo "`date`: ERROR: Unknown status code: $status" >> $SNAPLOG
logger -p user.err "ERROR when freezing $INST"
exit_code=1
;;
esac
echo "`date`: Completed freeze of $INST" >> $SNAPLOG
done
echo "`date`: Pre freeze script finished" >> $SNAPLOG
exit $exit_code
#!/bin/sh
#
# Script called by VMWare immediately after backup snapshot has been created
# Tested on Red Hat 7.2
#
LOGDIR=/var/log
SNAPLOG=$LOGDIR/snapshot.log
echo >> $SNAPLOG
echo "`date`: Post thaw script started" >> $SNAPLOG
exit_code=0
if [ -d "$LOGDIR" ]; then
# Only for running instances
for INST in `ccontrol qall 2>/dev/null | tail -n +3 | grep '^up' | cut -c5- | awk '{print $1}'`; do
echo "`date`: Attempting to thaw $INST" >> $SNAPLOG
# Detailed instances specific log
LOGFILE=$LOGDIR/$INST-pre_post.log
# Thaw
csession $INST -U%SYS "##Class(Backup.General).ExternalThaw(\"$LOGFILE\")" >> $SNAPLOG 2>&1
status=$?
case $status in
5) echo "`date`: $INST IS THAWED" >> $SNAPLOG
csession $INST -U%SYS "##Class(Backup.General).ExternalSetHistory(\"$LOGFILE\")" >> $SNAPLOG$
;;
3) echo "`date`: $INST THAW FAILED" >> $SNAPLOG
logger -p user.err "thaw of $INST failed"
exit_code=1
;;
*) echo "`date`: ERROR: Unknown status code: $status" >> $SNAPLOG
logger -p user.err "ERROR when thawing $INST"
exit_code=1
;;
esac
echo "`date`: Completed thaw of $INST" >> $SNAPLOG
done
fi
echo "`date`: Post thaw script finished" >> $SNAPLOG
exit $exit_code
# sudo chown root.root /usr/sbin/pre-freeze-script /usr/sbin/post-thaw-script
# sudo chmod 0700 /usr/sbin/pre-freeze-script /usr/sbin/post-thaw-script
スクリプトが正しく動作することをテストするには、VM でスナップショットを手動で実行し、スクリプトの出力を確認することができます。 以下のスクリーンショットは、［Take VM Snapshot（VM スナップショットの作成）］ダイアログとオプションを示します。
選択解除- ［Snapshot the virtual machine's memory（仮想マシンのメモリをスナップショットする）］
選択 - ［Quiesce guest file system (Needs VMware Tools installed)（ゲストファイルシステムを静止する: VMware ツールのインストールが必要）］チェックボックス。スナップショットを作成する際にゲストオペレーティングシステムで実行中のプロセスを一時停止し、ファイルシステムのコンテンツが既知の整合性のある状態を保つようにします。
重要！ テストの後、スナップショットを必ず削除してください！！！！
スナップショットが作成される際に、静止フラグが真であり、仮想マシンがオンである場合、VMware ツールによって仮想マシンのファイルシステムが静止されます。 ファイルシステムの静止は、ディスク上のデータをバックアップに適した状態にするプロセスです。 このプロセスには、オペレーティングシステムのメモリ内キャッシュからディスクへのダーティバッファのフラッシュといった操作が含まれる場合があります。
以下の出力は、操作の一環としてスナップショットを含むバックアップを実行した後に、上記の Freeze/Thaw スクリプトの例で設定された $SNAPSHOT ログファイルのコンテンツを示しています。
Wed Jan 4 16:30:35 EST 2017: Pre freeze script started
Wed Jan 4 16:30:35 EST 2017: Attempting to freeze H20152
Wed Jan 4 16:30:36 EST 2017: H20152 IS FROZEN
Wed Jan 4 16:30:36 EST 2017: Completed freeze of H20152
Wed Jan 4 16:30:36 EST 2017: Pre freeze script finished
Wed Jan 4 16:30:41 EST 2017: Post thaw script started
Wed Jan 4 16:30:41 EST 2017: Attempting to thaw H20152
Wed Jan 4 16:30:42 EST 2017: H20152 IS THAWED
Wed Jan 4 16:30:42 EST 2017: Completed thaw of H20152
Wed Jan 4 16:30:42 EST 2017: Post thaw script finished
この例では、Freeze から Thaw までに 6 秒経過していることがわかります（16:30:36～16:30:42）。 この間、ユーザー操作は中断されていません。 _独自のシステムからメトリックを収集する必要があります_が、背景としては、この例は、IO ボトルネックがなく、平均 200 万 Glorefs/秒、17 万 Gloupds/秒、および毎秒あたり平均 1,100 個の物理読み取りと書き込みデーモン 1 サイクル当たりの書き込み 3,000 個の BM でアプリケーションベンチマークを実行しているシステムから得たものです。
メモリはスナップショットの一部ではないため、再起動すると、VM は再起動して復元されることに注意してください。 データベースファイルは整合性のある状態です。 バックアップを「再開」するのではなく、ファイルを既知の時点の状態にする必要があります。 その後で、ファイルが復元されたら、ジャーナルと、アプリケーションとトランザクションの整合性に必要なその他の復元手順をロールフォワードできます。
その他のデータ保護を追加するには、ジャーナルの切り替えを単独で実行することもでき、ジャーナルは、たとえば 1 時間ごとに別の場所にバックアップまたは複製されます。
以下は、上記の Freeze と Thaw スクリプトの $LOGFILE の出力で、スナップショットのジャーナルの詳細を示しています。
01/04/2017 16:30:35: Backup.General.ExternalFreeze: Suspending system
Journal file switched to:
/trak/jnl/jrnpri/h20152/H20152_20170104.011
01/04/2017 16:30:35: Backup.General.ExternalFreeze: Start a journal restore for this backup with journal file: /trak/jnl/jrnpri/h20152/H20152_20170104.011
Journal marker set at
offset 197192 of /trak/jnl/jrnpri/h20152/H20152_20170104.011
01/04/2017 16:30:36: Backup.General.ExternalFreeze: System suspended
01/04/2017 16:30:41: Backup.General.ExternalThaw: Resuming system
01/04/2017 16:30:42: Backup.General.ExternalThaw: System resumed
VM スナップショットの作成時、バックアップが完了してスナップショットがコミットされた後、VM を短時間フリーズする必要があります。 この短時間のフリーズは、VM のスタンと呼ばれることがよくあります。 スタンタイムについてよく説明されたブログ記事は、こちらをご覧ください。 以下に要約した内容を示し、Caché データベースの考慮事項に照らして説明します。
スタンタイムに関する記事より: 「VM スナップショットを作成するには、（i）デバイスの状態をディスクにシリアル化し、（ii）現在実行中のディスクを閉じてスナップショットポイントを作成するために、VM は「スタン」されます（無応答状態になります）。… 統合時、VM は、ディスクを閉じて統合に最適な状態にするために、「スタン」されます。」
スタンタイムは、通常数百ミリ秒です。ただし、コミットフェーズ中にディスクの書き込みアクティビティが非常に高い場合には、スタンタイムが数秒に長引くことがあります。
VM が、Caché データベースミラーリングに参加するプライマリまたはバックアップメンバーであり、スタンタイムがミラーのサービス品質（QoS）タイムアウトより長引く場合、ミラーはプライマリ VM に失敗としてレポートし、ミラーのテイクオーバーを開始します。
2018 年 3 月更新: 同僚の Pter Greskoff から指摘されました。バックアップミラーメンバーは、VM スタン中またはプライマリミラーメンバーが利用不可である場合には、QoS タイムアウトの半分超という短時間でフェイルオーバーを開始することがあります。
QoS の考慮事項とフェイルオーバーのシナリオの詳細については、「Quality of Service Timeout Guide for Mirroring（ミラーリングのサービス品質タイムアウトに関するガイド）」という素晴らしい記事を参照できますが、以下に、VM スタンタイムと QoS に関する要約を示します。
バックアップミラーが、QoS タイムアウトの半分の時間内にプライマリミラーからメッセージを受信しない場合、ミラーはプライマリが動作しているかどうかを確認するメッセージを送信します。 それからバックアップはさらに QoS タイムアウトの半分の時間、プライマリマシンからの応答を待機します。 プライマリからの応答がない場合、プライマリは停止しているとみなされ、バックアップがテイクオーバーします。
ビジー状態のシステムでは、プライマリからバックアップミラーにジャーナルが継続的に送信されるため、バックアップはプライマリが動作しているかどうかを確認する必要はありません。 ただし、バックアップが発生している可能性が高い静止時間中、アプリケーションがアイドル状態である場合、QoS タイムアウトの半分以上の時間、プライマリとバックアップミラーの間でメッセージのやり取りがない可能性があります。
これは Peter が提示した例ですが、このタイムフレームを、QoS タイムアウトが :08 秒で VM スタンタイムが :07 秒のアイドル状態にあるシステムで考えてみましょう。
上記のリンク先の記事にある「Pitfalls and Concerns when Configuring your Quality of Service Timeout（サービス品質タイムアウトを構成する際の落とし穴と考慮事項）」のセクションもお読みください。QoS を必要な期間だけ確保する際のバランスが説明されています。 QoS が長すぎる場合、特に 30 秒を超える場合も問題を引き起こす可能性があります。
2018 年 3 月更新の終了:
ミラーリングの QoS の詳細については、ドキュメンテーションを参照してください。
スタンタイムを最小限に抑える戦略には、データベースアクティビティが低い場合にバックアップを実行することと、ストレージを十分にセットアップすることが挙げられます。
上記で述べたように、スナップショットの作成時に指定できるオプションがいくつかあります。その 1 つは、スナップショットにメモリ状態を含めることです。_Caché データベースのバックアップにはメモリ状態は不要である_ことに注意してください。 メモリフラグが設定されている場合、仮想マシンの内部状態のダンプがスナップショットに含められます。 メモリスナップショットの作成には、もっと長い時間がかかります。 メモリスナップショットは、実行中の仮想マシンの状態を、スナップショットが作成された時の状態に戻すために使用されます。 これは、データベースファイルのバックアップには必要ありません。
メモリスナップショットを作成する場合、仮想マシンの状態全体が停止しますが、スタンタイムはさまざまです。
前述のとおり、バックアップでは、整合性のある使用可能なバックアップを保証するために、手動スナップショットで、またはバックアップソフトウェアによって、静止フラグを true に設定する必要があります。
ESXi 5.0 より、スナップショットのスタンタイムは、以下のようなメッセージで仮想マシンのログファイル（vmware.log）に記録されます。
2017-01-04T22:15:58.846Z| vcpu-0| I125: Checkpoint_Unstun: vm stopped for 38123 us
スタンタイムはミリ秒単位であるため、上記の例にある 38123 us は 38123/1,000,000 秒または 0.038 秒となります。
スタンタイムが許容範囲内であることを確認するため、またはスタンタイムが長引くせいで問題が発生していると思われる場合にトラブルシューティングを実施するため、関心のある VM のフォルダから vmware.log ファイルをダウンロードして確認することができます。 ダウンロードしたら、以下の Linux コマンドの例を使うなどして、ログを抽出しソートできます。
vSphere 管理コンソールまたは ESXi ホストコマンドラインから VMware サポートバンドルを作成するなど、サポートログのダウンロードにはいくつかの方法があります。 全詳細については VMware ドキュメンテーションを参照できますが、以下は、スタンタイムを確認できるように、vmware.log ファイルを含む非常に小さなサポートバンドルを作成して収集する簡単な方法です。
VM ファイルが配置されているディレクトリの正式な名称が必要となります。 ssh を使用してデータベース VM が実行している ESXi ホストにログオンし、コマンド vim-cmd vmsvc/getallvms を使用して vmx ファイルとそれに関連付けられた一意の正式名称を一覧表示します。
たとえば、この記事で使用されているデータベース VM の正式な名称は次のように出力されます。 26 vsan-tc2016-db1 [vsanDatastore] e2fe4e58-dbd1-5e79-e3e2-246e9613a6f0/vsan-tc2016-db1.vmx rhel7_64Guest vmx-11
次に、ログファイルのみを収集してバンドルするコマンドを実行します。vm-support -a VirtualMachines:logs
コマンドによって、以下の例のように、サポートバンドルの場所が表示されます。 To see the files collected, check '/vmfs/volumes/datastore1 (3)/esx-esxvsan4.iscinternal.com-2016-12-30--07.19-9235879.tgz'.
これで、sftp を使用してファイルをホストから転送し、さらに処理して確認できるようになりました。
この例では、サポートバンドルを解凍した後に、データベース VM の正式名称に対応するパスに移動します。 この場合は、 <bundle name>/vmfs/volumes/<host long name>/e2fe4e58-dbd1-5e79-e3e2-246e9613a6f0 というパスになります。
そこで番号付きの複数のログファイルが表示されます。最新のログファイルには番号は付きません。つまり、vmware.log と示されます。 ログはわずか数百 KB ですが、たくさんの情報が記載されています。ただし、注目するのは stun/unstun の時間のみで、grep を使うと簡単に見つけ出すことができます。 次は、その記載例です。
$ grep Unstun vmware.log
2017-01-04T21:30:19.662Z| vcpu-0| I125: Checkpoint_Unstun: vm stopped for 1091706 us
---
2017-01-04T22:15:58.846Z| vcpu-0| I125: Checkpoint_Unstun: vm stopped for 38123 us
2017-01-04T22:15:59.573Z| vcpu-0| I125: Checkpoint_Unstun: vm stopped for 298346 us
2017-01-04T22:16:03.672Z| vcpu-0| I125: Checkpoint_Unstun: vm stopped for 301099 us
2017-01-04T22:16:06.471Z| vcpu-0| I125: Checkpoint_Unstun: vm stopped for 341616 us
2017-01-04T22:16:24.813Z| vcpu-0| I125: Checkpoint_Unstun: vm stopped for 264392 us
2017-01-04T22:16:30.921Z| vcpu-0| I125: Checkpoint_Unstun: vm stopped for 221633 us
この例では、2つのグループのスタンタイムを確認できます。1 つはスナップショップ作成時、そしてもう 1 つは、各ディスクのスナップショットが削除/統合された 45 分後（バックアップソフトウェアが読み取り専用 vmx ファイルのコピーを完了したとき）のものです。 上記の例では、最初のスタンタイムは 1 秒をわずかに上回っていますが、ほとんどのスタンタイムは 1 秒未満であることがわかります。
短時間のスタンタイムは、エンドユーザーが気付くものではありませんが、 Caché データベースミラーリングなどのシステムプロセスは、インスタンスが「アライブ」であるかどうかを継続的に監視しています。 スタンタイムがミラーリング QoS タイムアウトを超える場合、ノードは接続不可能であり「停止」状態とみなされ、フェイルオーバーがトリガーされます。
ヒント: すべてのログを確認するか、トラブルシューティングを実行する場合には、grep コマンドが役立ちます。すべての vmware*.log ファイルに対して grep を使用し、異常値、またはスタンタイムが QoS タイムアウトに達しているインスタンスを探してください。 以下のコマンドは、出力をパイプ処理し、awk で書式設定しています。
grep Unstun vmware* | awk '{ printf ("%'"'"'d", $8)} {print " ---" $0}' | sort -nr
通常稼働時に定期的にシステムを監視し、スタンタイムと、ミラーリングなどの HA 向けの QoS タイムアウトへの影響を理解しておく必要があります。 前述のとおり、スタンタイムまたはスタン解除タイムを最小限に抑える戦略には、データベースとストレージのアクティビティが低い場合にバックアップを実行することと、ストレージを十分にセットアップすることが挙げられます。 常時監視の場合、ログは、VMware ログのインサイトなどのツールを使用して処理できるかもしれません。
InterSystems データプラットフォームのバックアップと復元操作について、今後の記事で再度取り上げる予定です。 それまでは、システムのワークフローに基づいたコメントや提案がある場合は、以下のコメントセクションに投稿してください。
私たちのほとんどは、多かれ少なかれDockerに慣れ親しんでいます。 Dockerを使用している人たちは、ほとんどのアプリケーションを簡単にデプロイし遊んで、何かを壊してしまってもDockerコンテナを再起動するだけでアプリケーションを復元できる点を気に入っています。
InterSystems も Docker を気に入っています。
InterSystems OpenExchange プロジェクトには、InterSystems IRISのイメージを簡単にダウンロードして実行できるDockerコンテナで実行するサンプルが多数掲載されています。また、Visual Studio IRISプラグインなど、その他の便利なコンポーネントもあります 。
特定のユースケース用の追加コードを使ってDockerでIRISを実行するのは簡単ですが、ソリューションを他のユーザーと共有する場合は、コマンドを実行し、コードを更新するたびに繰り返し実行するための何らかの方法が必要になります。 この記事では、継続的インテグレーション／継続的デリバリー （CI / CD）を使ってそのプロセスを簡素化する方法を説明します。
セットアップ
InterSystemsのテクノロジースタックを使用して独自のアプリを開発し、顧客側で複数のデプロイを実行したいとします。 開発プロセスでは、クラスをインポートするだけでなく、必要に応じて環境を微調整する必要があるため、アプリケーションの詳細なインストールガイドを作成しました。この特定のタスクに対処するために、インターシステムズは、%Installer（Caché／Ensemble）という特別なツールを作成しました 。 続きを読んでその使用方法を学んでください。
%Installer
このツールを使用すると、インストール手順ではなく、目的のCaché構成を記述するインストールマニフェストを定義できます。作成したい Caché 構成を記述します。必要な内容を記述するだけで、環境を変更するために必要なコードが自動的に生成されます。
したがって、マニフェストのみを配布する必要がありますが、インストール・コードはすべてコンパイル時に特定の Caché サーバ用に生成されます。
前回はシンプルなIRISアプリケーション をGoogleクラウドにデプロイしました。 今回は、同じプロジェクトを Amazon Web Services（アマゾンウェブサービス） のElastic Kubernetes Service （EKS）を使って、デプロイします。
IRISプロジェクトをあなた自身のプライベート・リポジトリにすでにFORKしていると想定します。この記事では<username>/my-objectscript-rest-docker-templateという名前にしています。 <root_repo_dir>は、そのルートディレクトリです。
開始する前に、 AWSコマンドラインインターフェースと、Kubernetesクラスタ作成用のシンプルなCLIユーティリティeksctlをインストールします。 AWSの場合 aws2 の使用を試すことができますが、ここで説明するようにkube設定ファイルでaws2の使用法を設定する必要があります 。
AWS EKS
この連載記事では、InterSystemsの技術とGitLabを使用したソフトウェア開発に向けていくつかの可能性のあるアプローチを紹介し、説明したいと思います。以下のようなトピックについて取り上げます。
この記事では、独自のコンテナを構築してデプロイ展開する方法について説明します。
コンテナは一時的なものなので、アプリケーションデータを保存するべきではありません。Durable %SYS の機能により設定、構成、 %SYSデータなどをホストボリュームに保存することができます。
VMware vSphereで実行する大規模な本番データベースのCPUキャパシティプランニングについて、お客様やベンダー、または社内のチームから説明するように頼まれることが良くあります。
要約すると、大規模な本番データベースのCPUのサイジングには、いくつかの単純なベストプラクティスがあります。
このことから、通常いくつかの一般的な疑問が生まれます。