環境

組織の情報インフラストラクチャは、ソフトウェア開発と同じように進化します。インフラストラクチャでのあらゆる変更は、最終的に本番に至るまで、定義されたライフサイクルの一連の段階を経る必要があります。一般的なライフサイクルには、 開発ステージング本番 といった段階が含まれます。Denodo エコシステムでは、これらの段階のそれぞれを環境と呼びます。

構成の観点から見た場合、環境は、共通の目的のために連動する、同じタイプか異なるタイプの一連のサーバーとして定義されます。たとえば、環境を複数の Virtual DataPort サーバー、1 つの Scheduler サーバー、およびデータキャッシュとして機能する 1 つのデータベースサーバーで構成することができます。また、サーバーが依存するすべてのリソースとデータソースも環境の構成要素です。

環境の内部では、サーバーは 1 つまたは複数のクラスターに編成され、クラスターごとに 1 つのロードバランサーが設定されます。クラスターに着信するリクエストはすべてロードバランサーによって事前処理され、ロードバランサーが、クラスターに含まれている一連のサーバーの中から、最終的にクエリを処理するサーバーを決定します。このようにすることで、組織はシステムの高可用性を保証できます。

これを機能させるには、 同じ環境内のすべてのサーバーが同じメタデータを共有する必要があります 。これらのサーバーは同じリソースとデータソースを操作するためです。ただし、各環境で管理される一連のデータソースとリソースはその環境専用であるため、サーバーのメタデータは環境ごとに異なります。

Solution Manager を使用すると、ライフサイクル内で 1 つの環境から次の環境に変更を昇格できます。環境ごとにニーズが異なるため、整合性やサービス中断の面を考えて、Solution Manager には複数の変更デプロイ戦略が実装されています。これにより、各環境で固有のデプロイ戦略を構成できます。

クラスター

クラスターは、同じ環境に属する Denodo サーバーのグループです。

高可用性を保証するため、本番環境はロードバランサーの背後に 1 つまたは複数のクラスターとして編成し、ロードバランサーが最終的に着信リクエストを処理するサーバーを決定します。

また、本番環境では低遅延を実現する必要もあります。組織は複数のクラスターを地理的に分散することで、この要件を満たすことができます。たとえば、北米に 1 つ、ヨーロッパに 2 つ目、中国に 3 つ目というようにクラスターを配置できます。

一般的に 1 つのクラスターは、複数の Virtual DataPort サーバー、1 つの Scheduler サーバー、およびデータキャッシュとして機能する 1 つのデータベースサーバーで構成されます。

同じ環境内のすべての Virtual DataPort サーバーは同じメタデータを共有する必要があります。つまり、別の環境から変更を昇格する前に、Virtual DataPort サーバーへのデプロイに必要なプロパティを環境レベルで定義しておく必要があります。

一方で、Scheduler サーバーのメタデータはクラスターレベルで共有されます。Scheduler サーバーは、クラスターに対してローカルのサーバーまたはデータソースを参照するからです。このため、別の環境から変更を昇格する前に、Scheduler サーバーへのデプロイに必要なプロパティをクラスターごとに定義しておく必要があります。

動作モード

Solution Manager は、次の 2 つのモードで動作できます。

  • 標準: オンプレミスのクラスターで動作することを目的としたモード。クラスターのリソースを手動で追加する必要があります。

    このモードについては、「 標準モード 」を参照してください。

  • 自動: すべてのリソースが Solution Manager によって管理されます。管理者は必要な容量を設定するだけです。

    このモードについては、「 自動クラウドモード (AWS) 」を参照してください。