デプロイの構成¶
注釈
グローバル管理者および昇格管理者のみがデプロイの構成を変更できます。権限の詳細については、「 認可 」を参照してください。
環境のダイアログの [Deployments] セクションを使用すると、この環境がデプロイターゲットとして参加している場合に、デプロイをどのように機能させるかを構成できます。
注釈
環境でデプロイを有効にする前に、デプロイが機能する仕組みをよく理解しておくことが必要です。デプロイの仕組みについては、「 標準モードのデプロイ 」のセクションで説明しています。
以下のセクションでは、標準環境とクラウド環境の両方で使用できる構成に加え、Data Catalog の同期の構成についても説明します。
標準モード環境のデプロイの構成¶
標準環境へのデプロイを構成するためのダイアログ¶
標準モードの環境で構成できる一般的なオプションは、次のとおりです。
Enable deployments: このオプションが有効になっている環境のみがデプロイのターゲットとして動作できます。有効になっていないと、デプロイは失敗します。
Save backup in VCS when the deployment finishes: これをチェックすると、構成した バージョン管理システム にデプロイのバックアップが保存されます。バックアップは、有効な最初のクラスタにある有効な最初のサーバーのメタデータを使用して、正常に完了したデプロイと失敗したデプロイの両方に対して実行されます。
Execute rollback when the deployment fails in the first server: 環境内の有効な最初のクラスタにある有効な最初のサーバーがデプロイのテストベースとして動作します。このオプションをチェックした場合、そのサーバーでのデプロイが失敗すると、Solution Manager は、前回正常に完了したデプロイ時に バージョン管理システム に保存したバックアップを使用して、そのサーバーを前の状態に復元します。
Deployment type: Solution Manager がロードバランサーと情報をやり取りするかどうかに応じて、2 つのデプロイタイプがあります。
[Simple] のデプロイモードの場合、Solution Manager は、ロードバランサーと情報をやり取りせずに、サーバーのメタデータを 1 つずつ更新するだけです。このオプションは、オフラインアプリケーション用です。
[Without service interruption] のデプロイモードの場合、Solution Manager は、ロードバランサーで Virtual DataPort サーバーまたはクラスタを無効にして、デプロイの完了時にそれらを再び有効にします。ロードバランサーを操作するために、Solution Manager は [Deployment Scripts] セクションで定義されたスクリプトを使用します。
デプロイが [Without service interruption] として構成されている場合、昇格を実行するための戦略を複数の中から選択できます。実際に選択可能なオプションは、インフラストラクチャのトポロジーによって異なります。このトポロジーは、[Number of clusters installed] パラメータを使用して確認できます。このパラメータは、有効な Virtual DataPort サーバーが環境内に 1 つ以上ある有効なクラスタの数を示します。
有効なクラスタが 1 つだけ の環境の場合、[Promotion policy when the environment contains only one cluster] サブセクションで値を指定できます。
注釈
デプロイでは、クラスタが無効になっておらず、有効な Virtual DataPort サーバーが 1 つ以上ある場合、その クラスタは有効と見なされます 。また、サーバーが有効になっていて、そのサーバーが属するクラスタが有効な場合、その サーバーは有効と見なされます 。
環境に 1 つのクラスタが含まれる場合に指定可能な構成オプション¶
このようなシナリオでは、以下のオプションを構成できます。
Server promotion strategy: Solution Manager は、スクリプト Enable server in the load balancer および Disable server in the load balancer を使用して、ロードバランサーで Virtual DataPort サーバーをそれぞれ有効/無効にします (このプロセスでは、無効な Virtual DataPort サーバーは無視されます)。Solution Manager がサーバーを昇格する方法は、次の 2 通りあります。
[Half] の戦略では、まずロードバランサーで半数の Virtual DataPort サーバーを無効にして、デプロイを実行し、再び有効にします。次に、残りの半数に対してこのプロセスを繰り返します。このオプションでは、システムに不整合が生じた場合でも、短時間に抑えることができます。
[One By One] の戦略では、ロードバランサーでクラスタの最初の Virtual DataPort サーバー (Solution Manager のカタログツリーの順序に従う) を無効にして、デプロイを実行し、再び有効にします。このプロセスをサーバーごとに繰り返すので、システムに不整合が生じた場合、[Half] の戦略のときよりも長引く可能性があります。
Secondary shared cache available: Virtual DataPort サーバーのキャッシュに何も問題が生じないように、Solution Manager では、2 種類のキャッシュデータソースを定義して、デプロイごとに交互に使用することができます。デプロイ時にサーバーがメタデータを更新する際に、サーバーのキャッシュは、現在の (前の) データソースから、更新されたデータと、場合によっては更新されたスキーマを含むビューが格納された他方のデータソースに切り替わります。こうすることで、まだ更新されていないサーバーがキャッシュ内の変更の影響を受けることがなくなります。これを機能させるには、Virtual DataPort のキャッシュとして動作できる 2 種類の異なるスキーマが同じデータベースに存在する必要があります。
First cache URL: Virtual DataPort サーバーのキャッシュとして動作できる一方のスキーマの URL。
Second cache URL: Virtual DataPort サーバーのキャッシュとして動作できる他方のスキーマの URL。
重要
現在、 キャッシュ切り替えプロセスは、グローバルキャッシュに限定されています 。つまり、特定のデータベースに定義されるキャッシュは対象ではありません。
複数の有効なクラスタ で構成されている環境の場合、[Promotion policy when the environment contains more than one cluster] サブセクションで値を指定できます。
環境に複数のクラスタが含まれる場合に指定可能な構成オプション¶
このサブセクションには、[Cluster promotion strategy] オプションのみが含まれます。このオプションでは、昇格時にロードバランサーでクラスタを有効/無効にする方法を構成します。Solution Manager はこれを目的としてスクリプト Enable cluster in the load balancer および Disable cluster in the load balancer をそれぞれ使用します (このプロセスでは、無効なクラスタは無視されます)。選択できる戦略は、次の 2 つです。
[Half] の戦略では、まずロードバランサーで半数のクラスタを無効にし、これらのクラスタに定義されているサーバーにデプロイを実行して、クラスタを再び有効にします。次に、残りの半数に対してこのプロセスを繰り返します。このオプションでは、システムに不整合が生じた場合でも、短時間に抑えることができます。
[One By One] の戦略では、ロードバランサーで環境の最初のクラスタ (Solution Manager のカタログツリーの順序に従う) を無効にして、そのクラスタに含まれるサーバーにデプロイを実行して、クラスタを再び有効にします。このプロセスをクラスタごとに繰り返すので、システムに不整合が生じた場合、長引く可能性があります。
クラウド環境のデプロイの構成¶
クラウド環境へのデプロイを構成するためのダイアログ¶
クラウド環境に構成できる一般的なオプションは、次のとおりです。
Enable deployments: このオプションが有効になっている環境のみがデプロイのターゲットとして動作できます。有効になっていないと、デプロイは失敗します。
Minimize Downtime: デプロイの変更によりクラスタの再作成が必要になった場合に、再作成中にサーバーがサービスを提供するかどうかを指定します。
No: Solution Manager は、ロードバランサーが新しいサーバーの正常性チェックを完了するのを待たずにクラスタを再作成します。古いサーバーは新しいサーバーの追加後に削除されるため、サーバーがサービスを提供しない時間が生じます。このオプションは、オフラインアプリケーション用です。
Yes: Solution Manager は、ロードバランサーが新しいサーバーの正常性チェックを完了するのを待ってからクラスタを再作成し、古いサーバーを削除します。このオプションでは、サーバーで発生する可能性があるダウンタイムが最小限に抑えられます。
Data Catalog サーバーの同期¶
すべての環境タイプの Data Catalog サーバーを同期するように Solution Manager を構成することもできます。
Data Catalog サーバーの同期の構成¶
重要
デプロイプロセス中にカタログのメタデータを同期するために、各 Data Catalog サーバーを構成するユーザーには data_catalog_admin 以上の役割が必要です。
Data Catalog の同期で構成できるオプションは、次のとおりです。
Enable Data Catalog synchronization: Data Catalog サーバーは、このオプションが有効な場合にのみ同期されます。
Select the Data Catalog elements to synchronize: 同期するエレメントタイプを選択します (Data Catalog のエレメントの同期 と同じオプション)。
Views: ビューのメタデータを同期します。
Web services: Web サービスのメタデータを同期します。
All: 上記のすべてのタイプのメタデータを同期します。
Data Catalog synchronize priority: 同期の完了後、サーバーの現在のスキーマを反映するようにスキーマが更新されます。このときに、次の 3 つの方法のいずれかで説明を更新できます。
Server: 説明は、サーバーにある説明で上書きされます。
Local: Data Catalog のすべての説明が保持されます。
Server with local changes: 説明はサーバーにある説明で上書きされます。ただし、Data Catalog から編集されたものは例外で、それらの説明は保持されます。
Select the Data Catalog clusters to synchronize: 同期する Data Catalog サーバーが含まれるクラスタを選択します。有効な Data Catalog サーバーが 1 つ以上含まれるクラスタのみが同期されます。
Logical server name to synchronize: 任意。同期するサーバーの論理名を指定できます (この名前は、Data Catalog 内の Virtual DataPort サーバーの名前に対応します)。このフィールドは、Data Catalog サーバー内に複数の Virtual DataPort サーバーが含まれる場合にのみ構成する必要があります。
警告
[Logical server name to synchronize] フィールドが空の場合、Data Catalog サーバーに定義されているすべての Virtual DataPort サーバーのメタデータが同期されます。