新しいインストール環境に対するアップグレード前の作業¶
ここでは、以前のバージョンから設定とメタデータを インポートする前に 、Denodo Platform 9 と Solution Manager 9 の 新しいインストール環境 で完了する必要のある作業について説明します。
使用しないモジュールについては、アップグレード前の作業を省略してください。
すべてのモジュールに共通する作業¶
すべてのモジュールに共通する 作業は、Solution Manager のインストール環境 および Denodo Platform のインストール環境で行う必要があります。
暗号化キーのコピー¶
重要
このインストール後のタスクは、極めて重要です。この手順を実行する前に、Denodo Platform のどのコンポーネントも起動しないでください。これに従わないと、このインストール環境は 動作不能な状態 のままになる可能性があります。
Denodo Platform バージョン 9 または Solution Manager バージョン 9 、あるいはその両方をすでにインストールしている場合は、次の 2 つのファイルを一方の既存のインストール環境からこの新しいインストール環境にコピーします。
<DENODO_HOME>/conf/denodo-key.keystore
<DENODO_HOME>/conf/denodo-keystore.json
詳細については、管理ガイドの「 すべてのインストール環境への暗号化キーの複製 」を参照してください。
最新の更新プログラムのインストール¶
Denodo Platform と Solution Manager の 9 の最新の更新プログラム (存在する場合) をインストールします。手順の説明については、「 更新プログラムおよび修正プログラムのインストール 」のセクションを参照してください。
SSL の有効化¶
すべてのコンポーネントで SSL を有効にします。新規の秘密キーを取得しても、既存の秘密キーを再利用しても構いません。
既存の秘密キーを再利用するには、以下の手順に従って実施してください。
秘密キーを含むファイルを Denodo Platform 8.0 のインストール環境からコピーします。このファイルを見つけるには、ファイル
<DENODO_HOME_8_0>/conf/vdp/VDBConfiguration.properties}
を開いて、プロパティcom.denodo.security.ssl.keyStore
を検索します。このプロパティのファイルを新しいインストール環境にコピーします。この秘密キーの公開キーをエクスポートして、ファイル
<DENODO_HOME_9_0>/jre/lib/security/cacerts
にインポートします。cacerts ファイルを以前のバージョンから新しいバージョンにコピーしないでください。パブリック証明機関 (CA) の最新の証明書がないために、一部のサードパーティの HTTPS サービスに Denodo から接続できなくなるからです。
すべてのコンポーネントで SSL を有効にします。新しい Denodo SSL/TLS 構成スクリプト の使用をお勧めします。このスクリプトを実行すると、Denodo Platform と Solution Manager のインストール環境にあるすべてのコンポーネントのすべての構成プロパティが自動的に変更されます。ただし、バージョン 8.0 と同様に、これを引き続き手動で行うこともできます。
Windows サービスの構成¶
新しいバージョンを Windows にインストールし、すべてまたは一部のコンポーネントを Windows サービスとして実行する場合、これらのサービスを適切に構成します。手順については、『インストールガイド』の「 Windows サービスの構成 」を参照してください。
Kerberos: Krb5 ファイルのコピー¶
以下のどちらかを実行した場合、ここに示す手順を実行する必要があります。
いずれかのモジュールで Kerberos 認証を有効にした
Virtual DataPort に Kerberos 認証を使用して接続するデータソースがある
実行する手順:
Denodo 8.0 のインストール環境で、ディレクトリ
<DENODO_HOME_8_0>/jre/lib/security
にkrb5.conf
という名前のファイルがあることを確認します。このファイルが存在する場合、これを Denodo 9 のインストール環境のディレクトリ
<DENODO_HOME_9_0>/jre/conf/security
にコピーします。注釈
Denodo 7.0 またはそれ以前のバージョンからアップグレードする場合、Java Runtime Environment (JRE) 内の krb5 ファイルのデフォルトの場所が異なります。なぜなら、Denodo 9 は Java 17 を使用しますが、Denodo 7.0 および Denodo のそれ以前のバージョンは Java の古いバージョンを使用しており、このファイルを異なるディレクトリで探すからです。
Solution Manager に対しても同じ作業を行います (つまり、
<SOLUTION_MANAGER_HOME_7_0>/jre/lib/security/
を確認します)。
注釈
この時点では、Denodo 9 の新しいインストール環境で Kerberos 認証を 有効にしないでください 。アップグレードプロセスの途中で Virtual DataPort 8.0、7.0、または 6.0 のメタデータと設定をエクスポートしますが、これには Kerberos の構成と Kerberos の keytab 自体が含まれています。後で、これをすべてバージョン 9 にインポートします。
Virtual DataPort¶
Virtual DataPort: 外部データベースの有効化¶
Virtual DataPort 8.0 を、外部データベースを使用するように構成している場合、新しいバージョンでは異なるカタログ/スキーマを使用する必要があります。
これを行う方法については、『Virtual DataPort 管理ガイド』の「 外部データベースへのメタデータの保存 」を参照してください。
Virtual DataPort: データ一括読み込み API を使用する JDBC データソース¶
以下のどちらかに該当する場合、次のサブセクションに進んでください。
Denodo の現在のバージョンが 8.0 である
バージョン 7.0 または 6.0 と同じコンピュータに新しいバージョンをインストールしている
各 JDBC データソースを開いて、[Read & Write] タブでチェックボックス [Use Bulk Data Load] がチェックされ、フィールド [Work path] でファイルが指定されていることを確認します。確認できた場合、Denodo Platform 9 を 8.0 とは別のコンピュータにインストールしたのであれば、このデータベースのクライアントライブラリを新しいコンピュータにインストールします。
以下のデータベースのいずれかに接続するデータソースで一括読み込みを有効にした場合、Denodo 8.0 では、Hadoop ディストリビューションをダウンロードする必要がないように構成できることを考慮してください。
Hive 2.0
Impala
PrestoDB/Trino
Spark
Virtual DataPort: キャッシュエンジンの有効化¶
現在の Virtual DataPort でキャッシュエンジンを有効にしている場合、バージョン 9 でも有効にします。
前のセクション「 Virtual DataPort: キャッシュエンジン用のカタログ/スキーマの選択 」で、バージョン 8.0 と 9 のキャッシュエンジンに同じカタログ/スキーマを使用する場合と、別のものを使用する場合のメリットとデメリットを説明しています。
キャッシュエンジンを有効にした後で、バージョン 8.0 と 9 のデータソース vdpcachedatasource
(データベース admin
) の VQL を比較して、同じ内容であることを確認します。
データベースのキャッシュ構成
独自のキャッシュ構成を持つ Denodo データベースについても、同じ作業を行う必要があります。
バージョン 8.0 で次のクエリを実行して、独自のキャッシュ構成を持つデータベースのリストを取得します。
WITH global_cache_configuration AS ( SELECT database_datasource_name, datasource_name FROM get_cache_configuration() WHERE database_name IS NULL ) SELECT DISTINCT cache_configuration.database_name AS database_that_uses_its_own_cache_configuration, cache_configuration.database_datasource_name, cache_configuration.datasource_name FROM get_cache_configuration() cache_configuration, global_cache_configuration WHERE (cache_configuration.database_name IS NOT NULL) AND ( cache_configuration.database_datasource_name <> global_cache_configuration.database_datasource_name OR cache_configuration.datasource_name <> global_cache_configuration.datasource_name );
結果の最初の列は、独自にキャッシュを構成しているデータベースです。このクエリで 1 行も返されなかった場合、すべてのデータベースでグローバルなキャッシュ構成が使用されています。
各行に対して、以下の手順を バージョン 9.0 で実施します。
database_that_uses_its_own_cache_configuration という名前の列があるデータベースを作成します。
このデータベースで、バージョン 8.0 と同じようにキャッシュ構成を有効にします。なお、グローバルなキャッシュ構成と同様に、別のカタログ/スキーマを選択する必要がある場合もあります。
「汎用」アダプターを使用するキャッシュ構成
キャッシュエンジンが「汎用」アダプターを使用するように構成されている場合、ディレクトリ <DENODO_HOME_8_0>/conf/vdp
のファイル cacheConfig-generic.xml
と cacheConfig-generic-unicode.xml
を、ディレクトリ <DENODO_HOME_9_0>/conf/vdp
にコピーします。
Virtual DataPort: サードパーティコネクターのインストール¶
アップグレードプロセスの次の手順で、Virtual DataPort のメタデータをエクスポートするとき、作成されるファイルには JDBC データソースが使用している JDBC ドライバーが含まれています。ただし、他のコネクターは手動でインストールする必要があります。
Denodo 8.0 で以下のエレメントが存在する場合、そのコネクターを新しいバージョンにインストールします。
SAP BAPI データソース: 『Virtual DataPort 管理ガイド』の「 SAP Java Connector のインストール 」のページにある手順に従ってください。
すでに Denodo 8.0 にあるのと同じバージョンの SAP JcO を使用することもできます。新しいバージョンをダウンロードする必要はありません。
SAP に接続する多次元データソース: 『Virtual DataPort 管理ガイド』の「 SAP Java Connector のインストール 」のページにある手順に従ってください。
Oracle Essbase に接続する多次元データソース: 『インストールガイド』の「 Oracle Essbase 用コネクターのインストール 」のページにある手順に従ってください。
SOAP Over JMS を使用する JMS リスナーまたは Web サービス: 『Virtual DataPort 管理ガイド』の「 JMS コネクターをインストールしての、SOAP Over JMS を使用する JMS リスナーと Web サービスの作成 」のページにある手順に従ってください。
注釈
Denodo 7.0 以前からアップグレードする場合、上記のコネクターのインストール手順が変更されています。ファイルをインストール環境にコピーする代わりに、Design Studio を使用してコネクターをインストールしてください。
このクエリは、ユーザーが作成したさまざまなタイプのデータソースを返します。これを Denodo 8.0 サーバーで実行すると、上記のコネクターをインストールする必要があるかどうかがわかります。
SELECT DISTINCT subtype
FROM get_elements()
WHERE input_type = 'Datasources'
Virtual DataPort: 他のサードパーティ Jar ファイル¶
既存の Denodo インストール環境のフォルダ <DENODO_HOME_8.0>/extensions/thirdparty/lib
に移動し、以下のファイルを確認します。
Denodo 8.0 からアップグレードする場合、デフォルトのインストール環境ではこのフォルダは空です。ファイルが存在する場合、それらはインストール操作中に配置されたことを意味します。
Denodo 7.0 からアップグレードする場合、このフォルダには以下のファイルが存在します。
denodo-vdp-jdbcdriver.jar
derbyclient.jar
jtds.jar
ojdbc14.jar
postgresql.jar
その他のファイルが存在する場合、これらのファイルを必要とする Virtual DataPort の拡張機能がある、または過去にあったということです。以下の手順に従って、これらのファイルを Denodo 9 にインポートしてください。
その他のファイル (上記のリストにないファイル) を自分のコンピュータにコピーします。
Design Studio バージョン 9 に管理者アカウントでログインします。
[File] メニュー > [Extensions management] をクリックします。[Extensions] タブで [Import] をクリックします。
[Resource type] で [jar] を選択し、[Add] をクリックします。なお、この「エクスプローラー」に表示されているファイルの場所は自分のコンピュータであって、Virtual DataPort が稼動しているコンピュータではありません。さきほど Denodo 7.0 からコピーした 拡張子「jar」の付いた ファイルを選択します。
[Ok] をクリックしてから、再度 [Ok] をクリックし、Virtual DataPort にこれらのファイルをアップロードします。
以前のバージョンからコピーしたファイルに拡張子が「dll」または「so」のファイルがあった場合、再度 [Import] をクリックし、今度は [Resource type] で [library] を選択します。
インポートしたファイルを [Extensions management] ダイアログで確認するには、[Type] ボックスで [General] を選択します。
注釈
以前のバージョンでさきほどインストールしたコネクターのファイル (「 Virtual DataPort: サードパーティコネクターのインストール 」の作業) は Denodo 9 にインポートしないでください。
Virtual DataPort: バージョン管理システム¶
バージョン管理システム (VCS) サポートを使用している場合、これを有効にします。これを構成するときは、Denodo 9 用に作成したリポジトリを使用してください。すでにある 8.0 用のリポジトリは使用しないでください。
Virtual DataPort: 使用されないオブジェクトの削除¶
バージョン 8.0 で、メタデータをエクスポートする前に、今後使用されないオブジェクトの削除を検討してください。たとえば、ビューのないデータソース、テスト用に作成したビューとデータベースなどです。
Virtual DataPort: Aracne と Google Search のデータソースの削除¶
Denodo 8.0 からアップグレードする場合は、以下を無視してください。
Aracne と Google Search のデータソースは、バージョン 7.0 で非推奨となり、8.0 のリリース時に削除されました。これらが存在する場合、Virtual DataPort のメタデータをエクスポートする前にここで削除するか、後で現在の Denodo インストール環境から生成する VQL ファイルから削除します。
これらの種類のデータソースのリストを取得するには、次のクエリを実行します。
SELECT * FROM get_elements()
WHERE input_type = 'DataSources' AND (subtype = 'gs' or subtype = 'arn');
後で VQL ファイルを修正するよりも、ここで管理ツールから行う方が簡単です。そうした場合、データソースを削除すると、その基本ビューと基本ビューの派生ビューも自動的に削除されます。
Virtual DataPort - 公開 Web サービス: ロゴのカスタマイズ¶
REST Web サービスおよび RESTful Web サービスのロゴをカスタマイズしている場合、 同じ作業 を新しいインストール環境でも行ってください。
Virtual DataPort - Denodo Monitor: 情報をデータベースに保存するための構成¶
Denodo Platform インストール環境の Denodo Monitor を使用し、ログをデータベースに保存するように構成する場合、Denodo 9 のログ用に別のカタログ/スキーマを作成します。Denodo 8.0 のログに使用するのと同じカタログ/スキーマは使用しないでください。これが必要なのは、バージョン 9.0 のデータモデルが 8.0 とは異なるからです。
注釈
管理がしやすいという理由から、Denodo Platform インストール環境ごとに Denodo Monitor を実行するのではなく、Solution Manager の 監視 機能を使用することをお勧めします。その場合、このセクションは省略してください。
この機能を使用しているかどうかを確認するには、Denodo 8.0 のインストール環境でファイル <DENODO_HOME_8_0>/tools/monitor/denodo-monitor/ConfigurationParameters.properties
を開きます。vdpqueries.jdbcagent.enable
プロパティの値が true
で、このプロパティがコメント解除されている (つまり、先頭文字が #
ではない) 場合、この機能を使用しています。
この構成手順の詳細については、「 Denodo Monitor の構成 」を参照してください。ただし、基本的には、以下の手順を実行するだけで済みます。
パス
<DENODO_HOME_9_0>/tools/monitor/denodo-monitor/sql/
の SQL スクリプトを使用してカタログ/スキーマを作成します。このディレクトリには、さまざまなベンダー (DB2、MySQL、Oracle、PostgreSQL、および SQL Server) の SQL スクリプトがあります。ディレクトリ
<DENODO_HOME_8_0>/tools/monitor/denodo-monitor/lib/
内のファイルを<DENODO_HOME_9_0>/tools/monitor/denodo-monitor/lib/
にコピーします。
Data Catalog: 外部データベースの有効化¶
Data Catalog 8.0 を外部データベースを使用するように構成している場合、以下を行います。
外部データベースの JDBC ドライバーを新しいインストール環境にコピーします。具体的には、
<DENODO_HOME_8_0>/lib/data-catalog-extensions
の内容をディレクトリ<DENODO_HOME_9_0>/lib/data-catalog-extensions
にコピーします。この機能を有効にします。なお、新しいバージョンには別のカタログ/スキーマを使用する必要があります。
この手順については、『Data Catalog 管理ガイド』の「 Use an External Database for the Data Catalog 」を参照してください。
Scheduler: 外部データベースを有効にする¶
Scheduler 8.0 を、外部データベースを使用するように構成している場合、新しいバージョンでは異なるカタログ/スキーマを使用する必要があります。
この手順については、『Scheduler 管理ガイド』の「 Scheduler に外部データベースを使用する 」を参照してください。
Solution Manager¶
Solution Manager: 外部データベースの有効化¶
Solution Manager 8.0 を外部データベースを使用するように構成している場合、以下を行います。
このデータベースの JDBC ドライバーを新しいインストール環境にコピーします。具体的には、
<DENODO_HOME_8_0>/lib/solution-manager-extensions
から<DENODO_HOME_9_0>/lib/solution-manager-extensions
にコピーします。この機能を有効にします。なお、新しいバージョンには別のカタログ/スキーマを使用する必要があります。
Solution Manager: 高可用性¶
License Manager のセカンダリノードをセットアップしている場合、新しいバージョンに対しても同じように設定します。
Solution Manager: Git サポートの有効化¶
Solution Manager の Git サポートを使用している場合、新しいバージョンでそれを有効にします。必ず新しいリポジトリ、または新しいブランチを参照するようにしてください。
Solution Manager: JDBC アペンダーのモニタリングの構成¶
Solution Manager 8.0 で、Solution Manager のモニタリング機能を JDBC アペンダー を使用するよう構成していて、バージョン 9 でも同じようにする場合、以下の手順を実行します。
バージョン 9 のログ用に別のカタログ/スキーマを作成します。8.0 のログに使用するのと同じカタログ/スキーマは使用しないでください。これが必要なのは、バージョン 9.0 のデータモデルが 8.0 とは異なるからです。
データベースの JDBC ドライバーをコピーします。具体的には、ディレクトリ
<SOLUTION_MANAGER_HOME_8_0>/resources/solution-manager-monitor/denodo-monitor/lib
のファイルを<SOLUTION_MANAGER_HOME_9_0>/resources/solution-manager-monitor/denodo-monitor/lib
にコピーします。ディレクトリ
<SOLUTION_MANAGER_HOME_8_0>/lib/solution-manager-extensions
内のファイルを<SOLUTION_MANAGER_HOME_9_0>/lib/solution-manager-extensions
にコピーします。これは、Solution Manager が Monitor のメタデータを自動管理できるようにするために必要です。