サーバー設定¶
この構成領域は、複数のセクションに分かれています。
サーバー¶
サーバーポート¶
Scheduler サーバーは、クライアント通信にサーバー実行ポート、サーバー停止ポート、および補助ポートの 3 つのポート番号を使用します。
重要
Scheduler サーバーと管理ツールまたは他のクライアントが異なるマシンにインストールされている場合、サーバーがコネクションをリッスンするインターフェイスの変更が必要になる場合があります。そのためには、Denodo Control Center を開き、[Configuration] ダイアログを開いて [JVM Options] の [RMI Host] を変更します。詳細については、インストールガイドの「 Denodo Platform の構成 」のセクションを参照してください。こうした変更が必要な理由は、一部の環境では、「localhost」をリッスンする場合に、サーバーがリモートホストからのコネクションを許可しないためです。
注釈
顧客と Scheduler サーバー間のコネクションがファイアウォールを通過する必要がある場合、実行ポートと補助ポートへのアクセスを許可するようにファイアウォールを構成する必要があります。
注釈
サーバーポートの構成は Agora では無効化されます。
ポートの変更は、Scheduler サーバーの次回の再起動時に有効になります。
スレッドプール¶
注釈
スレッドプールの構成は Agora では無効化されます。
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] を超えない限り、新しいスレッドが作成されます。超えた場合、タスクは拒否されます。
タスクをキューに入れる操作を異なる間隔で所定の回数だけ再試行するための拒否ポリシーが存在します。
タスクは最大時間に達するまでキュー内でスレッドを待機します。
メール設定¶
このセクションでは、ジョブの実行時にレポートを送信するために使用する送信メールサーバー (「 ハンドラーセクション 」) のプロパティを変更できます。
以下の情報を指定できます。
SMTP server 。電子メールサーバーが稼働するマシンの名前。
Port 。サーバーが稼働するポートの番号。デフォルトは 25 です。
Protocol 。電子メールの送信に使用されるプロトコル (SMTP または SMTPS)。
From 。Scheduler がメールの送信に使用する電子メールアドレス。
Subject 。メールの件名。件名には変数を含めることができます。変数は実行時に対応する値に置き換えられます (値はジョブデータから取得します)。使用できる変数は、
projectName
、projectID
、jobName
、jobID
、jobStartTime
、および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。「*」を設定した場合、すべてのホストが信頼されます。複数のホストをスペースで区切って設定した場合、それらのホストが信頼されます。それ以外の場合、信頼できるかどうかは、サーバーが提示する証明書に基づいて判断されます。
Timeout。コネクションが確立された後にサーバーにメールを送信する間に待機する最大時間。「0」を設定すると、無期限に待機します。
Connection Timeout。サーバーへのコネクションが確立するのを待機する最大時間。「0」を設定すると、無期限に待機します。
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" />
Send as HTML。true の場合、メールで送信されたレポートは、XSLT テンプレート
<DENODO_HOME>/work/scheduler/mail/XMLtoHTML.xsl
を使用して HTML 形式に変換されます。それ以外の場合、レポートはプレーン文字列として送信されます。
注釈
これらのプロパティは、ローカル構成ファイル <DENODO_HOME>/conf/scheduler/ConfigurationParameters.properties
でコメントアウトまたは削除されている場合は、メタデータデータベースに保存されます。この場合、これらのプロパティは、クラスタ環境の複数の Scheduler サーバー間で共有されます。これらのプロパティの構成をあるノードで上書きする場合、そのノードのローカル構成ファイルで (Mail/<property>
で検索して) コメントを解除します。
注釈
メールで送信されたレポートをカスタマイズするには、XSLT ファイル <DENODO_HOME>/work/scheduler/mail/XMLtoHTML.xsl
を編集します。元のファイルのコピーが参照用に <DENODO_HOME>/setup/scheduler/mail/XMLtoHTML.xsl
に保存されます。
注釈
グローバル管理権限を持つユーザーは、 [View reports] セクション のコンテキストメニューから、 Mail Handler で構成され、メールで送信されたジョブのレポートの外観を確認できます。
さらに、送信メールサーバーで認証が必要な場合、ユーザー名 ([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 サーバーでの手順について説明します。
[Use Kerberos] を選択します。
[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 を必要に応じて使用できます。[Keytab file] ボックスに、 keytab ファイルのパスを入力します。
この Scheduler サーバーが稼働するホストが Kerberos レルム (例: Windows Active Directory ドメイン) に属していない場合を除き、[Configuration file] ボックスは空のままにします。このホストが Kerberos レルムに属して いない 場合は、以下のいずれかを実行します。
Kerberos 設定が含まれている
krb5.conf
ファイルまたはkrb5.ini
ファイルのパスを入力します。または、インストールガイドの付録「 Kerberos レルムに属することなく Kerberos 認証を有効化する 」で説明している手順に従います。
注釈
これは、Virtual DataPort データソースで Kerberos 認証を使用するために構成する必要がある唯一の設定です。
問題が発生した場合に備えて、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 のすべてのメタデータ (プロジェクトやジョブなど) がこのデータベースに保存されます。あるいは、メタデータを保存する別のデータベースを指定することも可能です。
注釈
ここでは、Scheduler Web Administration Tool を使用してメタデータデータベースを構成する方法について説明します。手動で構成する手順については、「 メタデータデータベースを手動で構成する方法 」を参照してください。
注釈
Agora では外部データベースは自動的に構成されるため、このオプションは Agora から Scheduler にアクセスする場合は無効化されます。
最初の手順では、Scheduler 9 に関するすべてのデータを保管するため、メタデータデータベースに専用のスキーマを作成することをお勧めします。この手順は必須ではありませんが、データを整理された状態に保ち、名前の重複を避けるために強くお勧めします。
外部データベースの推奨サイズに関して、明確な数値を示すのは困難です。数値は、特定のメタデータや、ジョブの実行数によって大きく変化するからです。ジョブの実行ごとにレポートを作成するため、実行数が多いほどレポート数も増し、レポートのサイズも大きくなります。レポートのサイズは、ジョブ実行時のエラーの数、ロードプロセスとインデックス作成プロセスの数、ジョブがパラメータ化されている場合はパラメータの数などによって変わります。このため、データベースに 5 GB の空き領域を確保することをお勧めします (ほとんどの場合、空き領域はこれより少なくても十分なはずですが、領域不足によるデータ破損を回避するため、高い値をお勧めしています)。
外部メタデータデータベースを構成する方法¶
外部メタデータデータベースのスキーマとテーブルを作成する自動モードを使用できます (ただし、引き続き 以前のモード を選択することもできます)。自動モードを使用するには、以下の手順に従います。
Scheduler サーバーを使用できなくなり、デフォルトのデータベース設定を復元する必要が生じる事態に備え、ファイル
<DENODO_HOME>/conf/scheduler/ConfigurationParameters.properties
をバックアップします。データベースメタデータ設定 フォームを使用して、新しいデータベースの設定を構成します。以下の情報を入力する必要があります。
Database Name:リレーショナルデータベースにアクセスするために使用される JDBC アダプターの名前。「 拡張機能 」で、Denodo Scheduler に付属のアダプターと、新しいアダプターの追加方法について説明しています。アダプターを選択すると、コネクション URI、ドライバークラスの名前、およびクラスパスの各フィールドが自動的に入力されます。コネクション URI の場合は、アクセスするリモートサーバーに応じて変更する必要のあるデータベースのコネクションテンプレートが表示されます。以下に示すデータベース (「 ドライバー 」に示されているドライバーのサブセット) から選択できます。
Amazon Aurora (MySQL)
Amazon Aurora (PostgreSQL)
Azure SQL Server
Derby (サーバーに組み込み済み)
MySQL
Oracle
PostgreSQL
SQL Server。SQL Server 向け jTDS ドライバーまたは Microsoft ドライバーを使用する場合に選択します。
注釈
各データベースのバージョンの最小要件は、Derby 10.15.1.3、MySQL 5.7、Oracle 12c、PostgreSQL 11、および Microsoft SQL Server 2014 です。
Connection URI: データベースアクセス URI。
Driver class name: 使用する JDBC アダプターの Java クラスの名前。
Driver class path:JAR ファイルと、JDBC アダプターで必要とされる実装クラスを含む、フォルダのパス。
Schema: (PostgreSQL および SQL Server のデータベースの場合のみ) スキーマの名前。このフィールドが空の場合は、データベースのデフォルトのスキーマが使用されます。
Authentication: 外部データベースにアクセスする際の認証方法を選択します。次のいずれかを選択できます。
ログインとパスワード: ユーザー名 (オプション) と パスワード (オプション) を使用します。
パスワードを用いた Kerberos 認証: ユーザー名 と パスワード (Active Directory アカウントを使用) を用いて Kerberos 認証を行います。
キータブを用いた Kerberos 認証: ユーザー名 (この場合、サービスプリンシパル名: SPN) とアップロードされた キータブファイル を用いて Kerberos 認証を行います (パスワードは不要)。
Windows ユーザーを用いた Kerberos 認証: Kerberos によるシングルサインオン (SSO) を使用して、サーバーを起動したユーザーのパススルー認証を行います (ユーザー名とパスワードは不要)。
注釈
Kerberos 認証は、データベースが Oracle または SQLServer の場合のみ使用可能です。
Denodo AWS インスタンス資格情報:
AWS IAM role ARN: 特定の権限を持つアカウントに作成できる IAM ID。
AWS region: Aurora データベースのデプロイ先である AWS リージョン。
Database user: アクセス先のデータベースアカウント。
AWS token life time (minutes): AWS 認証トークンが更新されるまで、そのトークンが Scheduler で保存されている時間。Scheduler では、この時間がデフォルトで 14 分とされています。 MariaDB、MySQL、および PostgreSQL の IAM データベース認証 では、トークンの有効期限がデフォルトで 15 分であるからです。
AWS IAM 資格情報: Denodo AWS インスタンス資格情報 のプロパティのほかに、以下のプロパティがあります。
AWS access key id: リクエスト元のユーザーまたはエンティティを指定する一意の ID。
AWS secret access key: AWS に対するリクエストへの署名に使用するシークレット文字列。
注釈
AWS IAM 資格情報 と Denodo AWS インスタンス資格情報 は、データベースが Amazon Aurora MySQL または Amazon Aurora PostgreSQL の場合にのみ使用できます。これらは SSL を必要とするので、「 AWS RDS 証明書を JRE cacerts に追加する 」の指示に従う必要があります。
必要に応じて メタデータのエクスポート パラメータをチェックすることで、現在のメタデータをエクスポートし、新しく構成されたデータベースにメタデータをインポートできます。現在のメタデータを新しいデータベースでも維持する場合は、この方法をお勧めします (そうでない場合、データベースの変更後にメタデータは失われます)。
注釈
エラーが発生した (設定が正しく構成されていない、新しいデータベースに接続できない) 場合は、アラートメッセージが送信されます。このメッセージは、エラー状態であることを知らせ、変更を受け入れると Scheduler サーバーを起動できなくなる可能性があることを警告します。ただし、Scheduler サーバーが使用不可能になった場合でも、手順 4. の
<DENODO_HOME>/conf/scheduler/ConfigurationParameters.properties
ファイルのバックアップを復元することで、デフォルトのデータベース設定を復元できます。Scheduler サーバーを再起動します。それ以降、以下のようになります。
Scheduler は新しく構成されたデータベースに対して実行されます。
新しく構成されたデータベースに Scheduler が使用するメタデータテーブルが自動的に作成されます。
注釈
正常に動作しない場合 (Scheduler で構成されているユーザーが構成されているデータベースでテーブルを作成する権限を持っていないなど) に備えて、サポートされている DBMS ごとの完全な .sql スクリプトが
<DENODO_HOME>/scripts/scheduler/sql
に用意されています。手順 2 でメタデータをエクスポートした場合は、そのメタデータを新しいデータベースに (「 インポート 」で説明したように) インポートします。
稼働時間の厳しい要件を満たすために、外部データベースの高可用性機能を有効にすることを検討してください。
外部メタデータデータベースを構成する方法 (廃止済み)¶
ここで説明する外部メタデータデータベースの構成方法は廃止されているため、「 外部メタデータデータベースを構成する方法 」の方法をお勧めします。引き続きこのモードを使用するには、以下の手順に従います。
<DENODO_HOME>/scripts/scheduler/sql
からスクリプトを実行して、新しいデータベースで Scheduler が使用するメタデータテーブルを作成します。サポートされている各データベース用に 2 つのスクリプトファイルが用意されています。最初に、
tables_<db_name>.sql
をロードします。次に、
drivers_metadata.sql
をロードします。
たとえば、Scheduler メタデータ用の新しいデータベースとして Oracle 12 を使用する場合、目的の Oracle 12 インスタンスに接続し、
<DENODO_HOME>/scripts/scheduler/sql/oracle
にあるスクリプトtables_oracle12.sql
およびdrivers_metadata.sql
を実行する必要があります。サポートされている他のデータベースについて同じ手順を実行します。
新しいデータベースのドライバーを
<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
にコピーします。サポートされている他のデータベースについて同じ手順を実行します。
Scheduler サーバーを使用できなくなり、デフォルトのデータベース設定を復元する必要が生じる事態に備え、ファイル
<DENODO_HOME>/conf/scheduler/ConfigurationParameters.properties
をバックアップします。Scheduler サーバーを再起動します。
データベースメタデータ設定 フォームを使用して、新しいデータベースの設定を構成します。以下の情報を入力する必要があります。
Database Name: 構成されたパラメータに対応するデータベース名を選択します。以下のデータベースから選択できます。
Amazon Aurora (MySQL)
Amazon Aurora (PostgreSQL)
Azure SQL Server
Derby (サーバーに組み込み済み)
MySQL
Oracle
PostgreSQL
SQL Server。SQL Server 向け jTDS ドライバーまたは Microsoft ドライバーを使用する場合に選択します。
Connection URI: データベースアクセス URI。
Driver class name: 使用する JDBC アダプターの Java クラスの名前。
Authentication: 外部データベースにアクセスする際の認証方法を選択します。次のいずれかを選択できます。
ログインとパスワード: ユーザー名 (オプション) と パスワード (オプション) を使用します。
パスワードを用いた Kerberos 認証: ユーザー名 と パスワード (Active Directory アカウントを使用) を用いて Kerberos 認証を行います。
キータブを用いた Kerberos 認証: ユーザー名 (この場合、サービスプリンシパル名: SPN) とアップロードされた キータブファイル を用いて Kerberos 認証を行います (パスワードは不要)。
Windows ユーザーを用いた Kerberos 認証: Kerberos によるシングルサインオン (SSO) を使用して、サーバーを起動したユーザーのパススルー認証を行います (ユーザー名とパスワードは不要)。
注釈
Kerberos 認証は、データベースが Oracle または SQLServer の場合のみ使用可能です。
必要に応じて メタデータのエクスポート パラメータをチェックすることで、現在のメタデータをエクスポートし、新しく構成されたデータベースにメタデータをインポートできます。現在のメタデータを新しいデータベースでも維持する場合は、この方法をお勧めします (そうでない場合、データベースの変更後にメタデータは失われます)。
注釈
エラーが発生した (jar ファイルが正しいフォルダにコピーされていないか、何らかの設定が誤っているか、メタデータテーブルが新しいデータベースに作成されていない) 場合は、アラートメッセージが送信されます。このメッセージは、エラー状態であることを知らせ、変更を受け入れると Scheduler サーバーを起動できなくなる可能性があることを警告します。ただし、Scheduler サーバーが使用不可能になった場合でも、手順 4. の
<DENODO_HOME>/conf/scheduler/ConfigurationParameters.properties
ファイルのバックアップを復元することで、デフォルトのデータベース設定を復元できます。Scheduler サーバーをもう一度再起動します。
それ以降、Scheduler は新しく構成されたデータベースに対して実行されます。
手順 5 でメタデータをエクスポートした場合は、そのメタデータを新しいデータベースに (「 インポート 」で説明したように) インポートします。
警告
クラスタ化されていない インスタンスを、他のインスタンスが実行されている、同じデータベーステーブルのセットに対して起動しないでください (クラスタの構成方法については次のセクションを参照してください)。深刻なデータ破損が発生する可能性があるほか、異常な動作が間違いなく発生します。
データベースへの接続数の制限方法¶
Denodo Scheduler では、メタデータデータベースへの接続にデータベース接続プールを使用します。
Scheduler サーバーごとに、 <DENODO_HOME>/conf/scheduler/ConfigurationParameters.properties
ファイルに以下のプロパティを手動で設定して、外部メタデータデータベースへの最大接続数と初期接続数を構成できます。
ComplexDataSource/maxConnections: 接続のプールで作成できるデータベース接続の最大数。デフォルト値は 100 です。 Quartz のドキュメント によると、少なくともスレッドプールのワーカースレッド数 + 3 にすることが推奨されています。Scheduler API を頻繁に呼び出す場合は、追加の接続が必要になることがあります。
ComplexDataSource/initialSize: Scheduler の起動時に接続のプールに作成されるデータベース接続の初期数。デフォルト値は 2 です。
注釈
現在、これらの設定を構成するためのグラフィカルサポートはありません。
クラスタ設定¶
クラスタリングは、クラスタの各ノードが同じデータベースを共有することで機能します。そのため、この機能を有効にする場合、Scheduler サーバーが共通のデータベースを使用するように構成する必要があります (「 データベースメタデータ設定 」を参照)。前のセクションの警告で説明したように、 クラスタ化されていないサーバーが他のサーバーと同じデータベースを使用するように構成してはなりません。したがって、クラスタリング機能を有効にせずに共通データベースを構成してはなりません (変更はサーバーの再起動後に有効になります)。
以下のパラメータを構成できます。
Cluster: クラスタリング機能をオンにするには、これを有効にします。前のサブセクションで説明したように、同じデータベーステーブルのセットを使用する Scheduler インスタンスが複数存在する場合は、このプロパティを「true」に設定する必要があります。
Node identifier: 任意の文字列を指定できますが、クラスタ内の Scheduler サーバーごとに一意でなければなりません。ID を自動生成する場合は、「AUTO」をノード ID の値として使用できます。
注釈
[Node Identifier] が「AUTO」の場合、自動生成される名前がデータベースでの保存に許可されている文字数 (45 文字) を超える可能性があり、文字数が制限を超えた場合は データ削除 例外がスローされます。この例外がスローされた場合は、適切なサイズの固定された名前 (クラスタのサーバーごとに一意) を設定してください。
Check interval: このインスタンスがクラスタの他のインスタンスに状況を報告する頻度を設定します (ミリ秒単位)。これは、障害が発生したインスタンスを検出する速さに影響します。推奨値は、たとえば 2000 ミリ秒または 3000 ミリ秒です。
これらの変更は、Scheduler サーバーの次回の再起動時に有効になります。
警告
クラスタリングを異なるマシンで実行している (つまり、Scheduler サーバーのすべてのインスタンスを同じマシンで実行していない) 場合、Scheduler サーバーのインスタンスが実行されているすべてのマシンのクロックが、定期的に実行される何らかの形式の時刻同期サービス (daemon) を利用して同期されている必要があります。利用する時刻同期サービスでは、クロック同士のずれが 1 秒以内になることが保証される必要があります。そうでないと、さまざまな異常な動作が発生する可能性があります。たとえば、あるノードが、他のノードでクラッシュが発生したと見なした場合に、ジョブのフェイルオーバー (複製) を実行する可能性があります。クラスタ内のすべてのノードのクロックを同期するには、 NTP などの時刻サービスを利用してください (「 NIST Internet Time Service 」も参照)。
Scheduler サーバーのクラスタの構成は高可用性 (HA) シナリオの鍵であり、以下の機能を提供します。
ロードバランシング: 自動的に行われ、クラスタの各ノードでジョブができるだけ速く実行されるようにします。トリガーの実行時刻になると、そのトリガーを (ロックすることによって) 取得した最初のノードが、トリガーを実行するノードになります。トリガーごとに 1 つのノードのみがジョブを実行します。毎回同じノードになるとは限りません。
フェイルオーバー: 1 つまたは複数のジョブの実行中にいずれかのノードで障害が起きた場合に発生します。あるノードで障害が起きると、他のノードがその状態を検知し、障害が起きたノードのデータベースで実行されていたジョブを識別して、残りのノードでそれらのジョブが再実行されます。ジョブ全体が再実行されるため、ファイルを生成するエクスポーターがいくつか使用されている場合は、ファイルが重複する可能性があります (ファイルが上書きされるように構成されていない場合)。また、これらのファイルは、クラスタ内の任意のサーバーからアクセスできる共有ドライブにエクスポートすることをお勧めします。
サーバー構成設定 (このセクションで前述した設定) は、インポート/エクスポート機能 (「 バックアップのインポート/エクスポート 」および「 バックアップのためのインポート/エクスポートスクリプトの使用 」を参照) を使用して、その構成を組み込むことによって、サーバー間で同期できます。
Scheduler サーバーをクラスタに追加する方法¶
Scheduler サーバーをクラスタに追加する必要がある場合は、以下の手順に従う必要があります。
クラスタに追加する Scheduler サーバーで、[クラスタ設定] に移動してクラスタリングを有効にします。
Scheduler サーバーを停止して起動すると、クラスタモードで起動します。
Scheduler の データベースメタデータ設定 を、クラスタ内の他のサーバーが使用するのと同じデータベースを使用するように変更します。
すべてのノードが同じ暗号化キーで構成されている必要があります。詳細については、「 インストール暗号化キー 」を参照してください。
注釈
データベースの変更は、必ずサーバーがクラスタモードになった後に実行してください。クラスタ化されていないサーバーが他のサーバーと同じデータベースを使用するように構成してはなりません。
重要
すべてのノードで同じ暗号化キーを使用せずにクラスタリングを有効にすると、Scheduler サーバーが正しく動作しないため、メタデータのリセットが必要になります。
Scheduler サーバーをクラスタから削除する方法¶
複数の Scheduler サーバーのクラスタを構成済みであり、それらの 1 つをクラスタから削除する必要がある場合は、以下の手順に従う必要があります。
他の Scheduler サーバーをすべて停止します。
クラスタから削除する Scheduler サーバーで、[クラスタ設定] に移動してクラスタリングを無効にします。
現在のデータベースはクラスタ内の他のサーバーと同じように構成されているため、その構成を変更して、メタデータが破損しないようにする必要があります (クラスタ化されていないサーバーが他のサーバーと同じデータベースを使用するように構成してはなりません)。
このサーバーがクラスタ内の最後のサーバーである場合、データベースの構成を保持できます (それがデータベース構成を持つ唯一のサーバーであることが想定されるため)。
すべての Scheduler サーバーを起動します。
Scheduler HA のベストプラクティス¶
複数の Scheduler サーバーのクラスタを構成した場合、それらすべてのサーバーが、ジョブを実行するために必要なリソースにアクセスできる必要があります (どのサーバーもあらゆるジョブを実行する可能性があるため)。
ジョブで生成されたファイル (CSV、SQL、およびカスタムエクスポーター形式) が共有ドライブにエクスポートされるようジョブを構成します。これにより、クラスタ内のどのサーバーもそれらのファイルにアクセスできるようになります。
アップロードされるファイルのパスを共有フォルダに変更します。これにより、クラスタ内のどのサーバーもアップロードされたファイルにアクセスできるようになります。 各サーバーで 、
<DENODO_HOME>/conf/scheduler/ConfigurationParameters.properties
を編集して以下のプロパティを変更します。CSVDataSourceStorer/csvFolder
: CSV データソースを作成したときにユーザーがアップロードする CSV ファイルが格納されます。