クラウドでのデプロイ¶
注釈
グローバル管理者、昇格管理者、および昇格ユーザーのみがリビジョンをデプロイできます。詳細については、「 認可 」を参照してください。
注釈
デプロイ時のサーバーに対する認証は、 Denodo Security Token を使用して実行されます。自動モードのクラウドサーバーでは、トークンの使用がデフォルトで構成されているため、構成を追加する必要はありません。
クラウド環境でのデプロイプロセスは、標準モード環境でのデプロイとは少し異なります。また、その動作は、 デプロイの構成 によって変わります。さまざまなオプションについて理解を深めるために、このセクションを読むことをお勧めします。
デプロイタイプが [Perform changes directly in the servers] の場合、Solution Manager は、クラスタの現在のサーバーで変更を実行します。変更は、以下のいずれかで実行されます。
デプロイの構成にに従いサーバーに共有メタデータ用データベースがない場合、すべての Denodo Virtual DataPort サーバー。このデプロイの基本的な手順は、 こちら で確認できます。
[VDP Servers use a shared metadata database] オプションが有効な場合、最初の Denodo Virtual DataPort サーバーのみ。このデプロイの基本的な手順は、こちら で確認できます。
クラウド環境では、共有メタデータ用データベースオプションが無効で、デプロイタイプが [Update the image and recreate the cluster] の場合、クラスタの現在のサーバーで変更が実行されるのではなく、新しいサーバーで変更が実行されてから、クラスタが再作成されます。クラウドでのこのデプロイタイプの主な手順は次のとおりです。
デプロイされるリビジョンの少なくとも 1 つに VQL の変更が含まれる場合、デプロイプロセスは次のようになります。
Solution Manager が、Virtual DataPort クラスタの最新のイメージを使用して新しいインスタンスを起動します。
新しい Virtual DataPort サーバーが起動して稼働すると、リビジョンの VQL が実行されます。
新しい Virtual DataPort サーバーを参照として使用して、Virtual DataPort クラスタが再作成されます。これにより、ダウンタイムが最小限に抑えられ、環境の構成の影響を受けることもありません。
リビジョンに Scheduler のジョブが含まれる場合は、次のようになります。
Solution Manager が、Scheduler クラスタの最新のイメージを使用して新しいインスタンスを起動します。
新しい Scheduler サーバーが起動して稼働すると、対象のジョブが作成される (CREATE リビジョンの場合) か、削除されます (DROP リビジョンの場合)。 CREATE リビジョンのデプロイでは、Scheduler のジョブは、リビジョンで実行対象のマークが付けられている場合に実行されます。
新しい Scheduler サーバーを参照として使用して、Scheduler クラスタが再作成されます。これにより、ダウンタイムが最小限に抑えられ、環境の構成の影響を受けることもありません。
デプロイ対象のリビジョンのいずれかに VQL の変更が含まれていて、環境に Data Catalog サーバーの同期が構成されている場合、対応する Data Catalog サーバーのメタデータは、指定されている構成に従って同期されます。
重要
VQL の実行または Scheduler タスクのインポートが失敗すると、デプロイは失敗します。この場合、対応する本番クラスタは変更されず、変更が実行されていた新しいクラウドサーバーは終了されます。
次の図は、すべてのタイプのサーバーが含まれるクラウド環境における一般的なデプロイプロセスの基本手順の概要を示しています。
1 つ以上のリビジョンをデプロイする には、 [Revisions] テーブル から ボタンまたは ボタンを使用する必要があることを忘れないでください。
デプロイの前提条件 は、標準環境の場合と同じです。
クラウドでのデプロイのオプション¶
Solution Manager では、 環境のデプロイ構成 で、クラウド環境でのデプロイプロセスの実行時にダウンタイムを最小化するためのオプションを指定できます。このオプションは、リビジョンの変更の実行後にクラスタが再作成される方法に影響します。相違点について、以下のセクションで説明します。
サーバーで直接変更を実行するデプロイ¶
次の図は、デプロイのタイプが [Perform changes directly in the servers] の場合の主な手順の概要を示しています。
警告
このオプションは通常最も高速ですが、デプロイ時に クラスタの容量に影響が及ぶ可能性がある ほか、 問題が発生した場合に手動での変更のロールバックが必要になる可能性があります (更新プログラム 8.0u20230301 以降は、自動ロールバックはこのオプションでのみ使用できます)。
ダウンタイムを最小化しない場合¶
次の図は、ダウンタイム最小化オプションを無効にしたデプロイプロセスでの、クラスタ再作成プロセスの主な手順の概要を示しています。
重要
このアプローチでは、新しいサーバーの準備が整ってロードバランサーの正常性チェックを完了する前に古いサーバーが終了されるため、プロセス中にサービスを使用することはできません。
ダウンタイムを最小化する場合¶
次の図は、デプロイプロセスのダウンタイムを最小化するクラスタ再作成プロセスの主な手順の概要を示しています。
重要
このオプションを使用すると、デプロイプロセス中にアプリケーションサービスを使用でき、ダウンタイムが最小化されます。ただし、旧バージョンのメタデータを使用するサーバーと新バージョンのメタデータを使用するサーバーが同時にサービスを提供する可能性があるため、クラスタの再作成中に不整合が生じることがあります。これは、新しいサーバーがサービスを提供する準備ができた時点で古いサーバーが終了され、その古いサーバーがリクエストを処理中であった場合に生じることがあります。
注釈
デプロイではこちらのオプションを使用することをお勧めします。
キャッシュに関する考慮事項¶
「 デプロイに関する考慮事項 」を参照し、キャッシュに関する考慮事項を確認してください。