標準モードのデプロイ¶
注釈
グローバル管理者、昇格管理者、および昇格ユーザーのみがリビジョンをデプロイできます。詳細については、「 認可 」を参照してください。
注釈
デプロイ時のサーバーに対する認証は、 Denodo Security Token を使用して実行されます。サーバーにトークン認証を構成しておく必要があります。
デプロイプロセスでは、環境内の Denodo サーバーで、1 つまたは複数のリビジョンに定義された変更をすべて実行します。具体的には次のとおりです。
リビジョンに Virtual DataPort エレメントが含まれる場合、対応する VQL は、環境に属しているすべての有効な Virtual DataPort サーバーで実行されます。
リビジョンに Scheduler のジョブが含まれる場合、これらのジョブは、環境に属している有効なクラスタそれぞれで最初の有効な Scheduler サーバーで作成される (CREATE リビジョンの場合) か、そのサーバーから削除されます (DROP リビジョンの場合)。 CREATE リビジョンをデプロイする場合、Scheduler のジョブは、リビジョンで実行対象のマークが付けられている場合に実行されます。
環境に Data Catalog サーバーの同期が構成されている場合、対応する Data Catalog サーバーのメタデータは、指定されている構成に従って同期されます。
Solution Manager は、まず 1 つのサーバーですべてのリビジョンを実行してから、次のサーバーの処理に進みます。サーバーが選択される順序は、カタログでサーバーがどのように編成されているかによって異なります。このため、ターゲット環境で最初の有効なクラスタにある最初の有効なサーバーが、最初にメタデータが更新されるサーバーになります。
重要
無効になっているクラスタ、および有効な Virtual DataPort サーバーがないクラスタは、デプロイプロセス中は無視されます。
重要
Scheduler のジョブは、環境の有効な各クラスタの最初の有効な Scheduler サーバーでのみ、作成または削除され、必要に応じて実行されます。
Scheduler のジョブは、クラスタの最初の Virtual DataPort サーバーで変更がデプロイされた後に実行されます。
Scheduler の各ジョブが適切に動作するには、ジョブがクラスタ内の最初の有効な Virtual DataPort サーバーを参照している必要があります 。これにより、Scheduler のジョブは、スキーマに変更があったビューを読み込む場合に適切に完了するようになります。
次の図は、一般的なデプロイプロセスの基本手順の概要を示しています。
デプロイプロセスの基本手順¶
デプロイプロセス中に実際に実行されるアクションは、ターゲット環境の デプロイ構成 で定義されます。
1 つ以上のリビジョンをデプロイする には、 [Revisions] テーブル から 
ボタンまたは 
ボタンを使用する必要があることを忘れないでください。
デプロイの前提条件¶
Solution Manager は、リビジョンをデプロイする前に以下を確認します。
ユーザーが以下のいずれかの権限を持っている。
ターゲット環境の構成でデプロイが有効になっている。
ターゲット環境に他に進行中のデプロイがない。
ターゲット環境に、有効な Virtual DataPort サーバーが 1 つ以上含まれる有効なクラスタが 1 つ以上ある。
リビジョンに Scheduler ジョブが 1 つ以上含まれる場合、環境内の有効なクラスタそれぞれに有効な Scheduler サーバーが 1 つ以上ある。
ターゲット環境の デプロイ 構成で Data Catalog の同期が有効になっている場合、この環境に Data Catalog が 1 つ以上登録されている。
ターゲット環境でリビジョンの Virtual DataPort プロパティがすべて定義されている。
ターゲット環境で不足しているプロパティがある場合は、この段階で検証の詳細を確認できます。詳細については、「 リビジョンの検証 」および「 リビジョンのデプロイ 」を参照してください。
有効な Scheduler サーバーが含まれる、ターゲット環境の有効なクラスタすべてで、リビジョンの Scheduler プロパティがすべて定義されている。
ターゲット環境のクラスタで不足しているプロパティがある場合は、この時点で検証の詳細を確認できます。詳細については、「 リビジョンの検証 」および「 リビジョンのデプロイ 」を参照してください。
サーバーにトークン認証が構成されている。詳細については、 Denodo Platform から Security Token Server へのコネクションの構成 に関するセクションを参照してください。
環境の構成が現在の環境のトポロジーに一致している。
さらに、Solution Manager は、環境の デプロイ構成 に応じて別の検証も実行します。これらの検証について、以下のセクションで説明します。
デプロイのパラダイム¶
Solution Manager には、デプロイプロセスを実行するためのオプションが複数用意されています。このセクションでは、それぞれのオプションの利点とトレードオフを評価します。
単純なデプロイ¶
このオプションでは、デプロイプロセス全体で アプリケーションサービスが使用できなくなる ことが前提となっています。このオプションは、オフライン昇格シナリオが対象です。
Solution Manager は、ロードバランサーでクラスタまたはサーバーを明示的に無効にすることなく、対応するサーバーすべてにリビジョンをデプロイします。
単純なデプロイでは、追加の検証を実行する必要はありません。
単純なデプロイのシナリオ¶
サービス中断なしのデプロイ¶
このオプションはオンライン昇格シナリオが対象で、デプロイプロセス中もアプリケーションサービスは使用可能なままです。ただし、旧バージョンのメタデータを使用するサーバーと新バージョンのメタデータを使用するサーバーが同時にサービスを提供する可能性があるため、デプロイの進行中に不整合が生じることがあります。
アプリケーションサービスを維持するために、Solution Manager は、ロードバランサーで Virtual DataPort サーバーまたはクラスタを無効にし、デプロイの完了時に再び有効にするスクリプトを実行します。ロードバランサーとのやり取りを制御するための昇格戦略は次のように 2 つあります。
One by one: 昇格は増分的に実行されます。一度に 1 つのサーバーまたはクラスタのみが無効になります (その後、有効になります)。これにより、 不整合の状態が長く なります。不整合の状態は、ターゲット環境内のクラスタまたはサーバーの数が多いほど、長くなります。
1 つずつの昇格戦略¶
Half by half: この戦略では、サーバーまたはクラスタの半分が同時に無効になります (その後、有効になります)。これにより、 不整合の状態は短く なります。
半分ずつの昇格戦略¶
昇格戦略はデプロイプロセスの所要時間には影響しません。ロードバランサーで同時に無効にするサーバーまたはクラスタの数にかかわらず、最終的なサーバーは 1 つずつ更新されます。
重要
Solution Manager は、デプロイプロセスが正常に完了したサーバーのみを有効にします。同様に、すべてのサーバーのデプロイプロセスが正常に完了したクラスタのみを有効にします。
サービス中断なしのデプロイに使用可能なオプションは、ターゲット環境のトポロジーによって異なります。
標準的な共有メタデータ用データベースのデプロイ¶
次の図は、 共有メタデータ用データベース をデプロイする際の主な手順をまとめたものです。このデプロイオプションは、 単純な デプロイの場合は、常に使用可能です。環境内に、Virtual DataPort サーバーを含む有効なクラスタが少なくとも 2 つある場合は、 サービス中断なしの デプロイでのみ使用可能です。
標準クラスタの共有メタデータ用データベースのデプロイ¶
このデプロイオプションでは、各クラスタ内の最初の有効な Virtual DataPort サーバーでのみ VQL の変更が実行されます。
警告
更新プログラム 8.0u20230301 以降は、自動ロールバックはこのオプションでのみ使用できます。
アクティブ/パッシブ負荷分散に関する考慮事項¶
アクティブ/パッシブクラスタは、1 つまたは複数のアクティブサーバー、1 つまたは複数のパッシブスタンバイサーバー、およびフェイルオーバーが必要なタイミングを判断する 1 つのロードバランサーで構成されます。
このようなアーキテクチャの環境の場合、各クラスタ内でサーバーを作成または順序付けする際には、 パッシブサーバーをアクティブサーバーの前 に配置することをお勧めします。
単一クラスタ環境でのサービス中断なしのデプロイ¶
このシナリオは、1 つ以上の Virtual DataPort サーバーで構成される クラスタが 1 つだけ 含まれる環境を対象としています。この場合、Solution Manager Administration Tool で以下を構成できます。
サーバー昇格戦略 。このポリシーにより、ロードバランサーで Virtual DataPort サーバーを 1 つずつ無効にするか、それとも半分ずつ無効にするかを設定します。
セカンダリ共有キャッシュ を使用可能にするかどうか。これを有効にする場合、メインキャッシュおよびセカンダリキャッシュの URL を指定する必要があります。
セカンダリ共有キャッシュのオプションは、すべてのサーバー間でキャッシュを共有するシナリオで有用です。このオプションを有効にしたデプロイでは、Solution Manager は以下を行います。
新しいキャッシュの URL の計算 。まず Solution Manager は、2 つの共有キャッシュのいずれ (プライマリまたはセカンダリ) が最初の Virtual DataPort サーバーに構成されているかを検出します。他方のキャッシュ、つまり現在使用されていない方のキャッシュが新しい共有キャッシュとして選択されます。
キャッシュの切り替え 。Virtual DataPort サーバーにすべてのリビジョンをデプロイする前に、各サーバーを新しいキャッシュに切り替えます。
すべての Scheduler VDP Cache ジョブの実行 。これは、最初の Virtual DataPort サーバーにリビジョンをデプロイした後にキャッシュにデータを取り込むために行います。
共有キャッシュを使用する単一クラスタ¶
重要
セカンダリ共有キャッシュのオプションは、Scheduler の VDP Cache ジョブを含む CREATE リビジョンが 1 つ以上含まれるデプロイにのみ適用されます。
重要
現在、 キャッシュ切り替えプロセスは、グローバルキャッシュに限定されています 。つまり、特定のデータベースに定義されるキャッシュは対象ではありません。
このシナリオでは、Solution Manager は以下のような追加の検証を実行します。
ターゲット環境に、ロードバランサーで Virtual DataPort サーバーを有効/無効にするためのスクリプトが提供されている 。
デプロイのターゲット環境に属するすべての Virtual DataPort サーバーとクラスタについて、 スクリプトの引数として使用する負荷分散変数すべてに値が定義されている 。
セカンダリ共有キャッシュが有効で、少なくとも 1 つの CREATE リビジョンに Scheduler の VDP Cache ジョブが含まれる場合、 すべての Virtual DataPort サーバーでキャッシュが有効になっている 。
複数クラスタ環境でのサービス中断なしのデプロイ¶
このシナリオは、1 つ以上の Virtual DataPort サーバーで構成される クラスタが複数 存在する環境を対象としています。この場合、Solution Manager Administration Tool で クラスタ昇格戦略 を構成できます。このポリシーにより、Virtual DataPort サーバーが含まれるクラスタをロードバランサーで 1 つずつ無効にするか、それとも半分ずつ無効にするかを設定します。
このシナリオでは、Solution Manager は以下のような追加の検証を実行します。
ターゲット環境に、ロードバランサーで クラスタを有効/無効にするためのスクリプトが提供されている 。
デプロイのターゲット環境に属するすべてのクラスタについて、 スクリプトの引数として使用する負荷分散変数すべてに値が定義されている 。
注釈
スクリプトの実行時に、実行時間が <SOLUTION_MANAGER_HOME>/conf/solution-manager/SMConfigurationParameters.properties ファイルの com.denodo.solutionmanager.scripts.timeoutInSeconds プロパティで定義されたタイムアウトに達すると、スクリプトは失敗します。このタイムアウトの単位は秒です。スクリプトで実行に時間がかかる複雑な操作を実行する場合は、このタイムアウトの値を大きくしてください。
キャッシュに関する考慮事項¶
「 デプロイに関する考慮事項 」を参照し、キャッシュに関する考慮事項を確認してください。