サーバー設定

この構成領域は、複数のセクションに分かれています。

サーバー

サーバーポート

Scheduler サーバーは、クライアント通信にサーバー実行ポート、サーバー停止ポート、および補助ポートの 3 つのポート番号を使用します。

重要

Scheduler サーバーと管理ツールまたは他のクライアントが異なるマシンにインストールされている場合、サーバーがコネクションをリッスンするインターフェイスの変更が必要になる場合があります。そのためには、Denodo Control Center を開き、[Configuration] ダイアログを開いて [JVM Options] の [RMI Host] を変更します。詳細については、インストールガイドの「 Denodo Platform の構成 」のセクションを参照してください。こうした変更が必要な理由は、一部の環境では、「localhost」をリッスンする場合に、サーバーがリモートホストからのコネクションを許可しないためです。

注釈

顧客と Scheduler サーバー間のコネクションがファイアウォールを通過する必要がある場合、実行ポートと補助ポートへのアクセスを許可するようにファイアウォールを構成する必要があります。

ポートの変更は、Scheduler サーバーの次回の再起動時に有効になります。


スレッドプール

Scheduler サーバーでは、さまざまな抽出ジョブを同時に実行できます。さらに、VDP、VDPCache、および VDPIndexer ジョブを使用すると、同じジョブでさまざまなパラメーターを指定し、同じデータソースに対して異なるクエリを同時に実行できます。

[Maximum number of concurrent jobs] パラメーターを使用すると、サーバーが同時に実行するジョブの最大数を指定できます (デフォルトは 20)。同時実行ジョブ数の変更は、Scheduler サーバーの次回の再起動時に有効になります。

VDP、VDPCache、および VDPIndexer ジョブでは、Scheduler サーバーは再利用可能なスレッドプールを使用して、同じジョブで生成できる複数のクエリの実行を管理します。構成可能なパラメーターは以下のとおりです。

  • Default number of threads (corePoolSize)。これは、非アクティブなスレッドが再利用されるプール内のスレッド数を表します (デフォルトは 20)。プール内のスレッドがこれより少ない場合、新しいスレッドが作成され続けます。スレッドがリクエストされ、プール内のスレッド数がこの値以上である場合、非アクティブなスレッドが存在すればそれらが返されます。存在しない場合は、以下のパラメーターで設定された値に達するまで新しいスレッドが作成され続けます。つまり、このパラメーターは、通常の負荷状態で同時にアクティブにする必要があるスレッドの数を示します。

  • Maximum number of threads (maximumPoolSize)。プールのスレッドの最大数を表します (デフォルトは 60)。

  • Keep alive timeout (ミリ秒)。スレッド数が [Default number of threads] で指定された合計数を超えている場合、非アクティブなスレッドがプールに保持される最大時間をミリ秒単位で指定します (デフォルトは 0)。値が 0 の場合、この値を超えて作成されたスレッドは、そのジョブが完了すると終了します。0 以外の場合、このパラメーターで指定された時間を超えるとスレッドは終了します。

このスレッドプールは、以下のように動作します。

  • エグゼキューターサービスには、実行される前のタスクを保持する内部キューがあります。

  • [Default number of threads] パラメーターは、プールでインスタンス化および保持されるコアスレッドの数です。

  • 新しいタスクが送信されると、以下の処理が実行されます。

    • [Default number of threads] より少ないスレッドが実行されている場合、 エグゼキューター は常に、リクエストをキューに入れるのではなく新しいスレッドを追加します。

    • [Default number of threads] 以上のスレッドが実行されている場合、 エグゼキューター は常に、新しいスレッドを追加するのではなくリクエストをキューに入れます。この場合の処理は以下のとおりです。

      • 内部キューがいっぱいでない場合、タスクはキューに保持されます。

        • このタスクが許容時間を超えてキューに保持されている場合、キューからタスクが取り出されてその実行が破棄されます。

      • 内部キューがいっぱいである場合、[Maximum number of threads] を超えない限り、新しいスレッドが作成されます。超えた場合、タスクは拒否されます。

        • タスクをキューに入れる操作を異なる間隔で所定の回数だけ再試行するための拒否ポリシーが存在します。

  • 結果は、以下のようになります。

    • 新しいスレッドは、キューがいっぱいである場合にのみ ([Maximum number of threads] に達するまで) 作成されます。

    • 実行するタスクがなくなると、キューがいっぱいにはならず、キューに入れられたタスクが実行するスレッドを取得することもなくなります。

      • タスクは最大時間に達するまでキュー内でスレッドを待機します。

注釈

スレッドのデッドロックを回避するために、[Default number of threads] と [Maximum number of threads] の両方に同じ値を設定することをお勧めします。そうすることで、固定サイズのスレッドプールが作成されます。

メール設定

このセクションでは、ジョブの実行時にレポートを送信するために使用する送信メールサーバー (「 ハンドラーセクション 」) のプロパティを変更できます。

以下の情報を指定できます。

  • SMTP server 。電子メールサーバーが稼働するマシンの名前。

  • Port 。サーバーが稼働するポートの番号。デフォルトは 25 です。

  • Protocol 。電子メールの送信に使用されるプロトコル (SMTP または SMTPS)。

  • From 。Scheduler がメールの送信に使用する電子メールアドレス。

  • Subject 。メールの件名。件名には変数を含めることができます。変数は実行時に対応する値に置き換えられます (値はジョブデータから取得します)。使用できる変数は、 projectNameprojectIDjobNamejobIDjobStartTime 、および jobResult で、形式は @{<var_name>} です。出力日付パターンを指定することで、 jobStartTime 変数の形式を設定できます。構文は、 @{jobStartTime,outputDateFormat:yyyy-MM-dd} です。以下に例を示します。

    Denodo Scheduler Notification - @{jobResult} [@{projectName}
    - @{jobName}_@{jobID}] at @{jobStartTime,outputDateFormat:yyyy-MM-dd HH:mm:ss}
    
  • Trust servers 。「*」を設定した場合、すべてのホストが信頼されます。複数のホストをスペースで区切って設定した場合、それらのホストが信頼されます。それ以外の場合、信頼できるかどうかは、サーバーが提示する証明書に基づいて判断されます。

  • Enable TLS 。true の場合、STARTTLS コマンドを使用して (サーバーでサポートされている場合)、ログインコマンドを発行する前に、TLS で保護されたコネクションに切り替えることができます。クライアントがサーバーの証明書を信頼するように該当のトラストストアを構成する必要があります。デフォルトは false です。

  • Enable debug 。true の場合、メールコネクションを追跡できます。また、以下のロガーを <DENODO_HOME>/conf/scheduler/log4j2.xml ファイルに追加する必要があります。

    <Logger name="com.denodo.scheduler.core.commons.utils.MailUtil" level="DEBUG" />
    

さらに、送信メールサーバーで認証が必要な場合、ユーザー名 ([Username]) とそのパスワード ([Password]) を指定する必要があります。

メールプロパティを構成したら、[Test mail configuration] リンクを使用してそれらが正しく構成されているかどうかをテストできます。テストメールの送信先電子メールアドレスを (「,」で区切って) 複数指定し、[Send email] をクリックします。構成が正しい場合、これらの受信者は、テスト用であることが本文に記載された電子メールを受け取ります。

認証

Virtual DataPort の設定

Denodo Scheduler サーバーは、ユーザーの認証を Denodo Virtual DataPort サーバーに委任できます (「 Authentication 」のセクションを参照)。さらに、Scheduler は、Virtual DataPort に接続してユーザーを認証するときにそのユーザーのロール (Scheduler でのユーザーのアクセス権限を決定する) も取得します。

そのため、Scheduler は認証とロールの取得に使用する Virtual DataPort サーバーに関する情報を知る必要があります。このセクションでは、以下の情報を指定できます。

  • Host 。Virtual DataPort サーバーが稼働するマシンの名前

  • Port 。Virtual DataPort サーバーが稼働するポートの番号

  • Database (オプション)。認証に使用される Virtual DataPort サーバーデータベースの名前 (データベースが LDAP 認証を使用する場合に有用)

これらのパラメーターの変更を有効にするには、いったんログアウトしてから再度ログインする必要があります。

注釈

このマニュアルですでに説明したように、管理者ユーザーは、Virtual DataPort サーバーに非ローカルユーザーとそのロールを作成する必要があります。また、VDP ベースの認証は、構成済みの Virtual DataPort サーバーとのコネクションが可能である場合にのみ実行できます (そうでない場合、実行できるのはローカルベースの認証のみです)。

Kerberos の設定

重要

シングルサインオン (SSO) を有効にするには、 Scheduler 管理ツール と Scheduler サーバーの 両方 で Kerberos を有効にする必要があります。ここでは、Scheduler サーバーでの手順について説明します。

  1. [Use Kerberos] を選択します。

  2. [Server Principal] ボックスに、 keytab ファイルの作成に使用する「サービスプリンシパル名」 (SPN) を入力します。これは、Scheduler サーバーが稼働しているサーバーの完全修飾ドメイン名 (FQDN) を含む SPN です。たとえば、「 HTTP/denodo-prod.subnet1.contoso.com@CONTOSO.COM 」のように入力します。

    注釈

    Scheduler サーバーの SPN は HTTP で始まる必要はありません。これが必須であるのは、Web ブラウザーが Kerberos チケットをリクエストする場合のみです。これは、Web ブラウザーは「 HTTP/<host name of the URL you are accessing> 」サービス用に Kerberos チケットをリクエストするためです。ここでは、Kerberos チケットはブラウザーではなく Scheduler 管理ツールによってリクエストされます。しかし、Scheduler 管理ツールの場合もブラウザーが Kerberos チケットをリクエストするため、SPN は HTTP で始まる必要があります。したがって、Scheduler サーバーでは、「 SCHED/denodo-prod.subnet1.contoso.com@CONTOSO.COM 」などの SPN を必要に応じて使用できます。

  3. [Keytab file] ボックスに、 keytab ファイルのパスを入力します。

  4. この Scheduler サーバーが稼働するホストが Kerberos レルム (例: Windows Active Directory ドメイン) に属していない場合を除き、[Configuration file] ボックスは空のままにします。このホストが Kerberos レルムに属して いない 場合は、以下のいずれかを実行します。

    1. Kerberos 設定が含まれている krb5.conf ファイルまたは krb5.ini ファイルのパスを入力します。

    2. または、インストールガイドの付録「 Kerberos レルムに属することなく Scheduler において Kerberos 認証を利用する 」で説明している手順に従います。

    注釈

    これは、Virtual DataPort データソースで Kerberos 認証を使用するために構成する必要がある唯一の設定です。

  5. 問題が発生した場合に備えて、Kerberos の初回設定時に、[Activate Kerberos debug mode] チェックボックスをチェックすることをお勧めします。Kerberos の設定が完了したら、チェックをはずします。

    このオプションが有効になっていると、Kerberos に関連したメッセージは、Java Runtime Environment によって、ログファイルにではなく標準出力に記録されます。これらのメッセージを確認するには、スクリプト <DENODO_HOME>/bin/scheduler_startup を使用してコマンドラインから Scheduler サーバーを起動します。

    重要

    Windows 環境では、サーバーの出力をファイルにリダイレクトする必要があります。そうしないと、Kerberos に関連するログメッセージを確認することはできません。

    これらのデバッグメッセージをファイルにリダイレクトするには、以下のようにサーバーを起動します。

    Windows の場合:

    cd <DENODO_HOME>
    cd bin
    scheduler_startup.bat > scheduler_kerberos_logging.log 2>&1
    

    Linux の場合:

    cd <DENODO_HOME>
    cd bin
    ./scheduler_startup.sh > scheduler_kerberos_logging.log 2>&1
    

このパラメーターの変更を有効にするには、サーバーを再起動する必要があります。

データベース

データベースメタデータ設定

Denodo Scheduler には、すぐに使用できる組み込みのデータベース (Apache Derby) が付属しており、Scheduler のすべてのメタデータ (プロジェクトやジョブなど) がこのデータベースに保存されます。データベースを編集するための各種設定のリンクをクリックすることで、別のデータベースをメタデータの保存先として指定できます。以下の情報を入力する必要があります。

  • Database Name: 構成されたパラメーターに対応するデータベース名を選択します。以下のいずれかを選択できます。

    • Derby (サーバーに組み込み済み)

    • MySQL

    • Oracle

    • PostgreSQL

    • SQL Server

    注釈

    Denodo Scheduler は、Derby 10、MySQL 5.6、MySQL 5.7、Oracle 11g、Oracle 12c、PostgreSQL 9.5、および SQL Server 2014 の各データベースでテスト済みです。

  • Connection URI: データベースアクセス URI。

  • Driver class name: 使用する JDBC アダプターの Java クラスの名前。

  • Username (オプション): 外部データベースへのアクセスに使用するユーザー名。

  • Password (オプション): 外部データベースへのアクセスに使用するユーザーパスワード。

  • Export metadata (オプション): このパラメーターをチェックすると、プロジェクトとエレメントがすべてエクスポートされ、構成した新しいデータベースに後からインポートできるようになります。新しいデータベースに現在のメタデータを維持したい場合は、このエクスポートを行うことを強くお勧めします。

警告

クラスター化されていない インスタンスを、他のインスタンスが実行されている、同じデータベーステーブルのセットに対して起動しないでください (クラスターの構成方法については次のセクションを参照してください)。深刻なデータ破損が発生する可能性があるほか、異常な動作が間違いなく発生します。

これらの設定を構成する前に、新しいデータベースドライバーを <DENODO_HOME>/lib/scheduler-extensions に組み込み、それらをロードするために Scheduler サーバーを再起動する必要があります。また、 <DENODO_HOME>/scripts/scheduler/sql からスクリプトを実行して、新しいデータベースで Scheduler が使用するメタデータテーブルを作成する必要もあります。サポートされている各データベース用に、 tables_<db_name>.sqldrivers_metadata.sql の 2 つのスクリプトファイルが用意されています。

再起動後、このフォームでこれらの設定を構成できます。変更は、再度サーバーを再起動した後に適用されます。[Export metadata] チェックボックスをチェックした場合、生成されたバックアップをインポートして、以前のメタデータをすべて、新しく構成したデータベースに配置します。

実行する必要がある手順の概要を以下に示します。

  1. データベース jar ファイルを <DENODO_HOME>/lib/scheduler-extensions にコピーします。

Scheduler メタデータ用の新しいデータベースとして Oracle 12 を使用する場合は、 <DENODO_HOME>/lib/extensions/jdbc-drivers/oracle-12c にある ojdbc6.jar ファイルと orai18n.jar ファイルのみを <DENODO_HOME>/lib/scheduler-extensions にコピーします。

サポートされている他のデータベースについて同じ手順を実行します。

  1. <DENODO_HOME>/scripts/scheduler/sql からスクリプトを実行して、新しいデータベースで Scheduler が使用するメタデータテーブルを作成します。

    1. サポートされている各データベース用に 2 つのスクリプトファイルが用意されています。

      1. 最初に、 tables_<db_name>.sql をロードします。

      2. 次に、 drivers_metadata.sql をロードします。

    Scheduler メタデータ用の新しいデータベースとして Oracle 12 を使用する場合、目的の Oracle 12 インスタンスに接続し、 <DENODO_HOME>/scripts/scheduler/sql/oracle-12c にあるスクリプト tables_oracle12.sql および drivers_metadata.sql を実行します。

    サポートされている他のデータベースについて同じ手順を実行します。

  2. Scheduler サーバーを再起動します。

  3. データベースメタデータ設定フォームを使用して、新しいデータベースの設定を構成します。

    1. オプションで、現在のメタデータをエクスポートします。

    2. エラーが発生した (jar ファイルが正しいフォルダーにコピーされていないか、何らかの設定が誤っているか、メタデータテーブルが新しいデータベースに作成されていない) 場合は、アラートメッセージが送信されます。このメッセージは、エラー状態であることを知らせ、変更を受け入れると Scheduler サーバーを起動できなく可能性があることを警告します。ただし、Scheduler サーバーが使用不可能になった場合でも、 <DENODO_HOME>/conf/scheduler/ConfigurationParameters.properties ファイルを手動で編集し、以下のようにプロパティを設定することで、デフォルトのデータベース設定を復元できます。

ComplexDataSource/driverClassName=org.apache.derby.jdbc.EmbeddedDriver
ComplexDataSource/url=jdbc:derby:schedulerDB
ComplexDataSource/user=derby
ComplexDataSource/password=derby

JobReportRepositoryFactory/className=com.denodo.scheduler.core.job.report.repository.DerbyJobReportRepositoryImpl

org.quartz.threadPool.class=org.quartz.simpl.SimpleThreadPool

org.quartz.jobStore.class=org.quartz.impl.jdbcjobstore.JobStoreTX
org.quartz.jobStore.driverDelegateClass=org.quartz.impl.jdbcjobstore.PostgreSQLDelegate
org.quartz.jobStore.useProperties=false
org.quartz.jobStore.dataSource=quartzds
org.quartz.jobStore.tablePrefix=QRTZ_

org.quartz.dataSource.quartzds.driver=org.apache.derby.jdbc.EmbeddedDriver
org.quartz.dataSource.quartzds.URL=jdbc:derby:schedulerDB
org.quartz.dataSource.quartzds.user=derby
org.quartz.dataSource.quartzds.password=derby
org.quartz.dataSource.quartzds.maxConnections=6
org.quartz.dataSource.quartzds.validationQuery=values(1)
  1. Scheduler サーバーをもう一度再起動します。

    1. それ以降、Scheduler は新しく構成されたデータベースに対して実行されます。

  2. 手順 4 でメタデータをエクスポートした場合は、そのメタデータを新しいデータベースに (「 インポート 」で説明したように) インポートします。

クラスター設定

クラスタリングは、クラスターの各ノードが同じデータベースを共有することで機能します。そのため、この機能を有効にする場合、Scheduler サーバーが共通のデータベースを使用するように構成する必要があります (「 データベースメタデータ設定 」を参照)。前のセクションの警告で説明したように、 クラスター化されていないサーバーが他のサーバーと同じデータベースを使用するように構成してはなりません。したがって、クラスタリング機能を有効にせずに共通データベースを構成してはなりません (変更はサーバーの再起動後に有効になります)。

以下のパラメーターを構成できます。

  • Cluster: クラスタリング機能をオンにするには、これを有効にします。前のサブセクションで説明したように、同じデータベーステーブルのセットを使用する Scheduler インスタンスが複数存在する場合は、このプロパティを「true」に設定する必要があります。

  • Node identifier: 任意の文字列を指定できますが、クラスター内の Scheduler サーバーごとに一意でなければなりません。ID を自動生成する場合は、「AUTO」をノード ID の値として使用できます。

  • Check interval: このインスタンスがクラスターの他のインスタンスに状況を報告する頻度を設定します (ミリ秒単位)。これは、障害が発生したインスタンスを検出する速さに影響します。推奨値は、たとえば 2000 ミリ秒または 3000 ミリ秒です。

これらの変更は、Scheduler サーバーの次回の再起動時に有効になります。

警告

クラスタリングを異なるマシンで実行している (つまり、Scheduler サーバーのすべてのインスタンスを同じマシンで実行していない) 場合、Scheduler サーバーのインスタンスが実行されているすべてのマシンのクロックが、定期的に実行される何らかの形式の時刻同期サービス (daemon) を利用して同期されている必要があります。利用する時刻同期サービスでは、クロック同士のずれが 1 秒以内になることが保証される必要があります。そうでないと、さまざまな異常な動作が発生する可能性があります。たとえば、あるノードが、他のノードでクラッシュが発生したと見なした場合に、ジョブのフェイルオーバー (複製) を実行する可能性があります。クラスター内のすべてのノードのクロックを同期するには、 NTP などの時刻サービスを利用してください (「 NIST Internet Time Service 」も参照)。

Scheduler サーバーのクラスターの構成は高可用性 (HA) シナリオの鍵であり、以下の機能を提供します。

  • ロードバランシング: 自動的に行われ、クラスターの各ノードでジョブができるだけ速く実行されるようにします。トリガーの実行時刻になると、そのトリガーを (ロックすることによって) 取得した最初のノードが、トリガーを実行するノードになります。トリガーごとに 1 つのノードのみがジョブを実行します。毎回同じノードになるとは限りません。

  • フェイルオーバー: 1 つまたは複数のジョブの実行中にいずれかのノードで障害が起きた場合に発生します。あるノードで障害が起きると、他のノードがその状態を検知し、障害が起きたノードのデータベースで実行されていたジョブを識別して、残りのノードでそれらのジョブが再実行されます。ジョブ全体が再実行されるため、ファイルを生成するエクスポーターがいくつか使用されている場合は、ファイルが重複する可能性があります (ファイルが上書きされるように構成されていない場合)。また、これらのファイルは、クラスター内の任意のサーバーからアクセスできる共有ドライブにエクスポートすることをお勧めします。

サーバー構成設定 (このセクションで前述した設定) は、インポート/エクスポート機能 (「 バックアップのインポート/エクスポート 」および「 バックアップのためのインポート/エクスポートスクリプトの使用 」を参照) を使用して、その構成を組み込むことによって、サーバー間で同期できます。

Scheduler サーバーをクラスターから削除する方法

複数の Scheduler サーバーのクラスターを構成済みであり、それらの 1 つをクラスターから削除する必要がある場合は、以下の手順に従う必要があります。

  • 他の Scheduler サーバーをすべて停止します。

  • クラスターから削除する Scheduler サーバーで、[クラスター設定] に移動してクラスタリングを無効にします。

  • 現在のデータベースはクラスター内の他のサーバーと同じように構成されているため、その構成を変更して、メタデータが破損しないようにする必要があります (クラスター化されていないサーバーが他のサーバーと同じデータベースを使用するように構成してはなりません)。

    • このサーバーがクラスター内の最後のサーバーである場合、データベースの構成を保持できます (それがデータベース構成を持つ唯一のサーバーであることが想定されるため)。

  • すべての Scheduler サーバーを起動します。

Scheduler HA のベストプラクティス

複数の Scheduler サーバーのクラスターを構成した場合、それらすべてのサーバーが、ジョブを実行するために必要なリソースにアクセスできる必要があります (どのサーバーもあらゆるジョブを実行する可能性があるため)。

  • ジョブで生成されたファイル (CSV、SQL、およびカスタムエクスポーター形式) が共有ドライブにエクスポートされるようジョブを構成します。これにより、クラスター内のどのサーバーもそれらのファイルにアクセスできるようになります。

  • アップロードされるファイルのパスを共有フォルダーに変更します。これにより、クラスター内のどのサーバーもアップロードされたファイルにアクセスできるようになります。 各サーバーで<DENODO_HOME>/conf/scheduler/ConfigurationParameters.properties を編集して以下のプロパティを変更します。

    • CSVDataSourceStorer/csvFolder: CSV データソースを作成したときにユーザーがアップロードする CSV ファイルが格納されます。