自動モード AWS 環境のベストプラクティス

ここでは、Solution Manager の 自動クラウドモード (AWS) を使用する上で考慮すべきベストプラクティスの要点を説明します。

アップタイムと可用性の最大化

  • 各クラスタが独自の Network Load Balancer を持つことで、すべてのインスタンスにトラフィックを分散し、高可用性を実現できます。

  • 本番環境のクラスタを作成する際は、[Launch instances in Auto Scaling Group] オプションを有効にすることをお勧めします。この機能を使用することで、インスタンスの Denodo コンポーネントが応答を停止した場合に、停止したインスタンスをクラスタが自動的に新しいインスタンスと置き換えます。

  • 利用可能であれば、[minimizing downtime] オプションの使用をお勧めします。これは、さまざまな クラスタ管理操作 (再作成、更新、インストールなど) と デプロイ の際にサービスを最大限活用するためです。

AWS インフラストラクチャをデプロイする際の考慮事項

  • 環境を作成する際はデータソースの所在地に近いリージョンを選択してください。つまり、Virtual DataPort が接続するデータソースの大部分が特定のリージョンに存在する場合、同じリージョンに環境を作成します。データ取得を高速化するためです。

  • 各環境を異なるリージョンに分散させて作成することを検討してください。これは、特定のリージョンのインフラストラクチャ障害によって、各環境が影響を受けないようにするためです。

  • すべての環境を同じリージョンに作成する場合は、可能であれば、各クラスタのサブネットを別々のアベイラビリティゾーンに配置してください。これにより、アベイラビリティゾーンの障害に対するフォールトトレランスを確保できます。

正常性チェック

Solution Manager には、Denodo デプロイ環境の正常性チェックを行う仕組みが複数存在します。

  • [Overview] 画面から、クラスタの状態を確認できます。Solution Manager は実行中のサーバーに定期的に ping を送信し、クラスタの状態を更新し続けます。

  • また、 追加チェック を実施して、コンポーネントが正常に可動しているかを確認できます。

  • Denodo Monitor を使用することで、Virtual DataPort サーバーの状態に関する詳細な情報を取得できます。

バックアップとリカバリー

  • システムのバックアップを行うには、 こちらの手順 に従って実施してください。

  • インスタンスの障害 が発生した場合

    • 本番クラスタでオートスケーリンググループを使用するように設定されている場合、ネットワークロードバランサーの正常性チェックとオートスケーリンググループによって、障害が発生したインスタンスの検出と置き換えが行われます。一時的にパフォーマンスが低下する可能性がありますが、データが失われることはなく、管理者の介入も不要です。

    • 本番クラスタがオートスケーリンググループを使用するよう設定されていない場合に、なんらかの障害を検出したときは、 クラスタを再起動 すると問題を解決できる可能性があります。

  • サービス制限 に達する可能性については、 AWS サービスクォータ を確認するとともに、 Amazon EC2 のサービスクォータ に特に注意してください。サービス制限に達した場合 (例: 他のコンポーネントとアカウントを共有している場合に、ネットワークロードバランサーの最大値に達した)、問題を解決するには、管理者に連絡して使用していないエレメントがあればそれを削除するか、影響を受けているリソースの制限を拡張してください。制限の問題が解決すると、Solution Manager Administration Tool から クラスタを再作成 してクラスタを修復し、再度稼働させることが可能になります。

  • アベイラビリティゾーンの障害 が発生した場合

    注釈

    別のアベイラビリティゾーンのサブネットを使用できない場合、使用しているアベイラビリティゾーンの復旧をお待ちください。

バックアップの復元

障害から復旧するには、最新のバックアップへの復元を行います。以下の手順に従って実施してください。

  • Solution Manager の最新バックアップへの復元

    1. バックアップ用に AMI を作成している場合、最新の AMI を使用して Solution Manager のインスタンスを再作成します。これを行うには、『 AWS クイックスタートガイド 』を参照してください。

    2. 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 時間未満を実現できます。

メンテナンス