自動モード環境のベストプラクティス¶
ここでは、Solution Manager の 自動クラウドモード を使用する上で考慮すべきベストプラクティスの要点を説明します。
アップタイムと可用性の最大化¶
各クラスタが独自の Network Load Balancer を持つことで、すべてのインスタンスにトラフィックを分散し、高可用性を実現できます。
本番環境のクラスタを作成する際は、[Launch instances in Auto Scaling Group] オプションを有効にすることをお勧めします。この機能を使用することで、インスタンスの Denodo コンポーネントが応答を停止した場合に、停止したインスタンスをクラスタが自動的に新しいインスタンスと置き換えます。
利用可能であれば、[minimizing downtime] オプションの使用をお勧めします。これは、さまざまな クラスタ管理操作 (再作成、更新、インストールなど) と デプロイ の際にサービスを最大限活用するためです。
インフラストラクチャをデプロイする際の考慮事項¶
環境を作成する際はデータソースの所在地に近いリージョンを選択してください。つまり、Virtual DataPort が接続するデータソースの大部分が特定のリージョンに存在する場合、同じリージョンに環境を作成します。データの取得を高速化するためです。
各環境を異なるリージョンに分散させて作成することを検討してください。特定のリージョンのインフラストラクチャ障害によって、各環境が影響を受けないようにするためです。
すべての環境を同じリージョンに作成する場合は、可能であれば、各クラスタのサブネットを別々のアベイラビリティゾーンに配置してください。これにより、アベイラビリティゾーンの障害に対するフォールトトレランスを確保できます。
正常性チェック¶
Solution Manager には、Denodo デプロイ環境の正常性チェックを行う仕組みが複数存在します。
[Overview] 画面から、クラスタの状態を確認できます。Solution Manager は実行中のサーバーに定期的に ping を送信し、クラスタの状態を更新し続けます。
また、 追加チェック を実施して、コンポーネントが正常に可動しているかを確認できます。
Denodo Monitor を使用することで、Virtual DataPort サーバーの状態に関する詳細な情報を取得できます。
バックアップとリカバリー¶
システムのバックアップを行うには、 こちらの手順 に従ってください。
インスタンスの障害 が発生した場合
本番クラスタでオートスケーリンググループを使用するように設定されている場合、ネットワークロードバランサーの正常性チェックとオートスケーリンググループによって、障害が発生したインスタンスの検出と置き換えが行われます。一時的にパフォーマンスが低下する可能性がありますが、データが失われることはなく、管理者の介入も不要です。
本番クラスタがオートスケーリンググループを使用するよう設定されていない場合に、なんらかの障害を検出したときは、 クラスタを再起動 すると問題を解決できる可能性があります。
サービス制限 に達する可能性については、 AWS サービスクォータ を確認するとともに、 Amazon EC2 のサービスクォータ に特に注意してください。Azure の場合、「Azure サブスクリプションとサービスの制限、クォータ、制約 <https://docs.microsoft.com/azure/azure-resource-manager/management/azure-subscription-service-limits>`_ 」で詳細を確認してください。サービス制限に達した場合 (例: 他のコンポーネントとアカウントを共有している場合に、ネットワークロードバランサーの最大値に達した)、問題を解決するには、管理者に連絡して使用していないエレメントがあればそれを削除するか、影響を受けているリソースの制限を拡張してください。制限の問題が解決すると、Solution Manager Administration Tool から クラスタを再作成 してクラスタを修復し、再度稼働させることが可能になります。
アベイラビリティゾーンの障害 が発生した場合
クラスタの構成 から、別の アベイラビリティゾーン を指定してください。
注釈
別のアベイラビリティゾーンのサブネットを使用できない場合、使用しているアベイラビリティゾーンの復旧をお待ちください。
バックアップの復元¶
障害から復旧するには、最新のバックアップに復元します。以下の手順に従ってください。
Solution Manager の最新バックアップへの復元
バックアップ用の AMI やイメージを作成した場合、最後の AMI やイメージを使用して Solution Manager のインスタンスを再作成します。それには、 インスタンスの起動ウィザード の手順に従うか、 マネージドイメージからの VM の作成 で詳細を確認してください。
AMI を作成する代わりに、Solution Manager のインストール環境のファイルをコピーした場合は、次の手順に従ってください。
新しいインスタンスに Solution Manager をインストールします。
Solution Manager Web ツールを使用してライセンスファイルを復元します (
<SOLUTION_MANAGER_HOME>/conf/denodo.lic
からコピーしておいたファイルです)。TLS が有効な場合は、「 Solution Manager での SSL/TLS の有効化 」の手順に従ってください。バックアップの作成時にコピーしたキーストアファイル (例:
denodo_server_key_store
) を使用します。外部データベースを使用する場合、次の作業を行います。
ディレクトリ
<SOLUTION_MANAGER_HOME>/lib/solution-manager-extensions/
のファイルを復元します。外部データベースを使用するように、Solution Manager を再構成します。データベースの内容は、Solution Manager と同じインスタンスには保存されていないため、失われていないはずです。
Solution Manager の JSON 構成ファイルをインポートし、メタデータを復元します。詳細については、 こちら を参照してください。
組み込みの Derby データベースを使用する場合、リビジョンと昇格の情報は失われます。これを回避するには、外部データベースを使用してください。
注釈
Solution Manager の復元にかかる時間は、ストレージの要件と選択したバックアップ手段によって異なります。
AMI やイメージを使用したバックアップ: 通常、RTO (目標復旧時間) 45 分未満、RPO (目標復旧時点) 24 時間未満を実現できます。
AMI やイメージを使用しないバックアップ: 通常、RTO (目標復旧時間) 1 時間未満、RPO (目標復旧時点) 24 時間未満を実現できます。
Denodo Platform のコンポーネントの最新バックアップを復元するには、 クラスタを再作成 します。必ず、各インスタンスに最新の AMI やイメージを使用してください。
注釈
クラスタの復元にかかる時間はストレージの要件と選択したバックアップ手段によって異なります。通常、RTO (目標復旧時間) 30 分未満、RPO (目標復旧時点) 24 時間未満を実現できます。
メンテナンス¶
セキュリティ上の理由から、 アクセスキー をローテーションしたほうがよいでしょう。次のいずれかの方法を使用できます。
セキュリティ上の理由から、Azure 資格情報もローテーションしたほうがよいでしょう。これも、以下のようにアクセスキーと同様の方法で行えます。
利用可能な最新の更新プログラムをインストールしてください。次のいずれかの方法を使用できます。
Solution Manager Administration Tool を使用して、 最新の更新プログラム をインストールします。容易であり、 推奨 される手法です。
もしくは、インスタンスに 手動で 更新プログラムをインストールし、 そのインスタンスからクラスタを再作成して 、クラスタの他のインスタンスに変更を反映します。