環境¶
組織の情報インフラストラクチャは、ソフトウェア開発と同じように進化します。インフラストラクチャでのあらゆる変更は、最終的に本番に至るまで、定義されたライフサイクルの一連の段階を経る必要があります。一般的なライフサイクルには、 開発 、 ステージング 、 本番 といった段階が含まれます。Denodo エコシステムでは、これらの段階のそれぞれを環境と呼びます。
構成の観点から見た場合、環境は、共通の目的のために連動する、同じタイプか異なるタイプの一連のサーバーとして定義されます。たとえば、環境を複数の Virtual DataPort サーバー、1 つの Scheduler サーバー、およびデータキャッシュとして機能する 1 つのデータベースサーバーで構成することができます。また、サーバーが依存するすべてのリソースとデータソースも環境の構成要素です。
環境の内部では、サーバーは 1 つまたは複数のクラスタに編成され、クラスタごとに 1 つのロードバランサーが設定されます。クラスタに着信するリクエストはすべてロードバランサーによって事前処理され、ロードバランサーが、クラスタに含まれている一連のサーバーの中から、最終的にクエリを処理するサーバーを決定します。このようにすることで、組織はシステムの高可用性を保証できます。
これを機能させるには、 同じ環境内のすべてのサーバーが同じメタデータを共有する必要があります 。これらのサーバーは同じリソースとデータソースを操作するためです。ただし、各環境で管理される一連のデータソースとリソースはその環境専用であるため、サーバーのメタデータは環境ごとに異なります。
Solution Manager を使用すると、ライフサイクル内で 1 つの環境から次の環境に変更を昇格できます。環境ごとにニーズが異なるため、整合性やサービス中断の面を考えて、Solution Manager には複数の変更デプロイ戦略が実装されています。これにより、各環境で固有のデプロイ戦略を構成できます。
注釈
同一環境内のすべてのサーバーには同一バージョンの Denodo Platform をインストールする必要があります。
クラスタ¶
クラスタは、同じ環境に属する Denodo サーバーのグループです。
高可用性を保証するため、本番環境はロードバランサーの背後に 1 つまたは複数のクラスタとして編成し、ロードバランサーが最終的に着信リクエストを処理するサーバーを決定します。
また、本番環境では低遅延を実現する必要もあります。組織は複数のクラスタを地理的に分散することで、この要件を満たすことができます。たとえば、北米に 1 つ、ヨーロッパに 2 つ目、中国に 3 つ目というようにクラスタを配置できます。
一般的に 1 つのクラスタは、複数の Virtual DataPort サーバー、1 つの Scheduler サーバー、およびデータキャッシュとして機能する 1 つのデータベースサーバーで構成されます。
同じ環境内のすべての Virtual DataPort サーバーは同じメタデータを共有する必要があります。つまり、別の環境から変更を昇格する前に、Virtual DataPort サーバーへのデプロイに必要なプロパティを環境レベルで定義しておく必要があります。
一方で、Scheduler サーバーのメタデータはクラスタレベルで共有されます。Scheduler サーバーは、クラスタに対してローカルのサーバーまたはデータソースを参照するからです。このため、別の環境から変更を昇格する前に、Scheduler サーバーへのデプロイに必要なプロパティをクラスタごとに定義しておく必要があります。
差分ウィザード¶
Solution Manager では、異なる環境 (1 つのソースと 1 つのターゲット) の 2 つの Denodo サーバーのメタデータを比較して、ターゲット環境で必要な変更を確認し、それに基づいてリビジョンを作成します。
この機能については、「 環境の比較ウィザードからのリビジョンの作成 」を参照してください。