Oracle Big Data SQLは、Hadoopクラスタ管理サーバーとOracle Databaseサーバーの両方にインストールする必要があります。この項では、単一ノード・システム、RACシステムなどOracle DatabaseシステムでのOracle Big Data SQL 3.2.1のインストールについて説明します。
インストールを開始する前に、この項のポイントを確認します。
Oracle Big Data SQLの現在のバージョンがOracle Databaseシステムにすでにインストールされており、既存の構成に変更を加えている場合は、インストール・プロセス全体を繰り返す必要はありません。「既存のOracle Big Data SQLインストールの再構成」を参照してください。
重要:
マルチノード・データベース(Oracle RACシステムなど)の場合、このインストールをデータベースの各コンピュート・ノードで繰り返す必要があります。これを実行していない場合、Oracle Big Data SQLサービスを開始すると、RPC接続エラーが表示されます。
インストーラの実行時に、オプションの--ip-cellコマンドライン・パラメータを含めて、そのノードの正しいネットワーク・インタフェース・アドレスを渡すことで、同じインストール・バンドルを各データベース・ノードで再利用できます。このパラメータが使用されていない場合、インストーラがそれを検索して選択します。
Gridが稼働中のデータベース・ノードのルートにはパスワードなしSSHを設定することをお薦めします。そうしないと、各ノードでインストール時に資格証明を指定する必要があります。
インストールの前にまだdiskmonプロセスが稼働していない場合、インストールを完了するためには、Gridインフラストラクチャの再起動が必要になります。
複数のHadoopクラスタから同じデータベースへのOracle Big Data SQL接続を設定する場合は、各接続の構成が同じであることを確認してください。インフィニバンドを使用する接続とイーサネットを使用する接続を設定しないでください。同様に、1つの構成でデータベース認証を有効にする場合は、異なるHadoopクラスタと同じデータベース間のすべてのOracle Big Data SQL接続でこの機能を有効にする必要があります。
データベース・システムがKerberosで保護されている場合、データベース所有者プリンシパルの認証を実行できるのは1つのKDCのみであることに留意してください。Oracle Big Data SQLは、現時点では複数のKerberosチケットをサポートしていません。複数のHadoopクラスタ接続が同じデータベース所有者によってインストールされる場合は、すべてが同じKDCを使用する必要があります。
KRB5_CONF環境変数は、1つの構成ファイルのみを指している必要があります。構成ファイルが存在している必要があり、変数自体はシステム起動時にデータベース所有者アカウントに対して設定されている必要があります。
Oracle Grid Infrastructureの下で実行しているデータベースに、同じタイプの複数のネットワーク・インタフェース(2つ以上のEthernet、2つ以上のInfiniBandまたは2つ以上のEthernet-over-InfiniBandインタフェース)が存在していると、常に、インストールによってアルファベット順で最初になる名前のインタフェースが選択されます。
関連項目:
詳細は、「Grid Infrastructureのシステムに同じタイプの複数のネットワーク・インタフェースがある際の特別な考慮事項」を参照してください。
特定のデータベース環境では、bds-database-install.shでcellinit.oraまたはcelliniteth.ora(あるいはその両方)を作成する必要があります。このような場合、スクリプトは同じような変更をGridインフラストラクチャ内のすべてのノードに伝播しようとします。このために、スクリプトではoracleとroot間にパスワードなしSSHを設定することが要求されるか、または実行時にノードごとにルートのパスワードが求められます。変更の性質によってGridインフラストラクチャの再起動が必要となる場合、スクリプトによってGridインフラストラクチャを手動で再起動する必要があることを示すメッセージも表示されます。再起動が必要な場合、Gridの資格証明なしではインストールを完了することはできないため、Gridのパスワードが手元にあることを確認してください。
Oracle Big Data SQLのデータベース側では、diskmonプロセスはHadoopクラスタとの通信の役割を担うエージェントです。これはOracle Exadata Database Machine上の機能と同様、コンピュート・ノードとストレージ・ノード間の通信を管理します。
Grid環境では、diskmonはGridユーザーによって所有されます。Grid環境以外では、Oracle Databaseの所有者によって所有されます。
Oracle Big Data SQLでは、diskmon設定は、/etc/oracle/cell/network-config/ディレクトリ内のcellinit.oraおよびcelliniteth.oraファイル上に格納されます。クラスタの接続要件に従い、インストーラによってこれらのファイルは更新されます。
これは、いつGridまたはOracle Databaseを再起動する必要があるかどうかを判断するための方法です。
インストーラで旧版のcellinit.oraまたはcelliniteth.oraファイルが存在しないことが検出された場合、いずれのdiskmonプロセスも実行していないことを意味します。このような場合、環境にOracle Gridが含まれているのであれば、Gridを再起動する必要があります。環境にGridが含まれていない場合は、Oracle Databaseを再起動する必要があります。
旧版のcellinit.oraまたはcelliniteth.oraファイル(あるいはその両方)が存在する場合は、diskmonプロセスが実行していることを示します。この場合、インストーラでこれらのファイルに変更を加える必要がなければ、データベースのみを再起動する必要があります。
マルチノードのGrid環境では、diskmonはすべてのノード上で単一のコンポーネントとして機能し、cellinit.oraおよびcelliniteth.oraがすべてのノード上で同期化される必要があります。このタスクは、SSHを介して行われます。クラスタ上でパスワードなしSSHが設定されている場合は、ユーザーの操作は必要ありません。パスワードなしSSHが設定されていない場合は、スクリプトは一時停止し、すべてのノードに対してrootの資格証明を入力することが求められます。すべてのノード間のcellinit.oraおよびcelliniteth.oraファイルが同期化されている場合は、スクリプトは続行します。その後、スクリプトが完了し、この場合はGridインフラストラクチャを再起動する必要があります。
こうした環境では、セルとの通信に間違ったIPアドレスが選択されることが原因で、Oracle Big Data SQLインストールやSmartScan操作が失敗する可能性があります。
Oracle Grid Infrastructure内にOracle Big Data SQLをインストールするときに、ノード上のOracle Big Data SQLセルとの通信用に特定のIPアドレスを選択するようにインストーラに指定できません。この環境では、ネットワーク・インタフェースの選択が自動的に判断されます。この判断は間違っていることがあり、データベース側のインストールに失敗するインスタンスが存在する場合や、SmartScanが機能していないことが後に判明する場合があります。
この問題は手動で解決できますが、まず、どのネットワーク・インタフェースがインストールで選択されるかを理解しておくことが役立ちます。
Grid Infrastructureのシステムにある同じタイプの複数のインタフェースからインストールが選択する方法
diskmonプロセスは、データベースではなくOracle Grid Infrastructureによって制御されます。Oracle Big Data SQLセルとの通信は、Gridによって管理されます。
このような場合は、Oracle Big Data SQLインストーラによってcellinit.oraとcelliniteth.oraが作成されることも、これらのファイルに保存されているセルの設定が更新されることもありません。こうした環境では、Gridによってタスクが処理されます(すべてのノード間で同期する必要があるクラスタ全体のタスクであるため)。
複数のネットワーク・インタフェースがある場合、セルに対するGrid管理の更新では、それぞれのノードで適切なタイプの最初のネットワーク・インタフェースが自動的に選択されます。その際、アルファベット順で最初になる名前の付いたインタフェースが選択されます。その他の環境(Exadata Database Machineシステムを除く)では、インストーラに--ip-cellコマンドライン・パラメータを使用することで、特定のネットワーク・インタフェースを選択できます。Grid環境では、このパラメータは無視されます。
次の例は、Grid Infrastructureのシステムを示しています。このシステムには、複数のInfiniBand、EthernetおよびEthernet over InfiniBand (bondeth*)ネットワーク・インタフェースがあります。インタフェースのリストは次のとおりです。
[root@mynode ~]# ip -o -f inet addr show 1: lo inet 127.0.0.1/8 2: eth0 inet 12.17.207.156/21 3: eth1 inet 16.10.145.12/21 19: bondeth0 inet 12.17.128.15/20 20: bondeth2 inet 16.10.230.160/20 21: bondeth4 inet 192.168.1.45/20 30: bondib0 inet 192.168.31.178/21 31: bondib1 inet 192.168.129.2/21 32: bondib2 inet 192.168.199.205/21 33: bondib3 inet 192.168.216.31/21 34: bondib4 inet 192.168.249.129/21
このシステムでOracle Big Data SQLインストーラが実行されると、次に示すインタフェースが選択されます。
cellinit.oraで構成されたInfiniBand接続には、192.168.31.178/21が選択されます。
このシステムにあるInfiniBandインタフェースのうち、アルファベットの昇順ソートで最初になるインタフェース名はbondib0です。
celliniteth.oraで構成されたEthernet-over-InfniBand接続には、12.17.128.15/20が選択されます。
注意:
この例では、標準イーサネットよりもEthernet over InfiniBandが優先されるという追加の選択要因が示されています。この場合、bondeth0というインタフェース名が最初になります。
このような条件下でインストール(またはSmartScan)が失敗することがある理由
diskmonは、前述のロジックに従って選択されたネットワーク・インタフェースを通じてOracle Big Data SQLのセルに接続できない可能性があります。正しいサブネット(diskmonにアクセス可能なもの)は、アルファベット順で最初に表示されない場合があります。
問題を修正する方法
このIPアドレスは、cellinit.oraファイルとcelliniteth.oraファイルで手動で変更できます。これらのファイルは、各ノードの/etc/oracle/cell/network-configにあります。
CRSプロセスを停止します。(セルの編集前に必ず実行してください。実行していないと、diskmonがハングする可能性があります)。
cellinit.oraとcelliniteth.oraのどちらか(または両方)を編集します。IPアドレスを必要に応じて変更します。
CRSを再起動します。
インストールのデータベース側を開始するには、データベース側のインストール・バンドルを解凍し、含まれている実行ファイルを実行します。実行ファイルによって、$ORACLE_HOME/BDSJaguar-3.2.1の下にインストール・ディレクトリが作成されます。次に例を示します。
$ORACLE_HOME/BDSJaguar-3.2.1/cdh510-6-node1.mycluster.mydomain.com
Oracle Big Data SQLのインストールは、このディレクトリの作成時には完了していません。ディレクトリは、データベース・ノードでインストールを完了するために必要なすべてのファイルが含まれているステージング領域です。
データベースと複数のHadoopクラスタ間にOracle Big Data SQL接続を確立できます。各接続は個別のデータベース側のインストールを介して確立されるため、個別のインストール・ディレクトリが作成されます。インストール・ディレクトリの名前に含まれるセグメントにより、この特定の接続でのHadoopクラスタを識別できます。
<Hadoop cluster name>-<Number nodes in the cluster>-<FQDN of the cluster management server node>
このディレクトリを保持する必要があります。これは、インストールの最新の状態を取得し、必要に応じてそれを使用してインストールを再生成できます。さらに、今後Hadoopクラスタの変更にあわせてインストールのデータベース側の調整が必要になった場合、Jaguarのreconfigureコマンドまたはupdatenodesコマンド、あるいはその両方によって生成された更新がこのディレクトリに適用されます。
oracle (または他のデータベース所有者)以外のユーザーによってインストール・ディレクトリが変更または削除されないように、権限の適用を検討してください。
Oracle Big Data SQLのデータベース側をインストールするには、Hadoopクラスタ管理サーバーに作成されたデータベース側のインストール・バンドルが含まれているZipファイルをコピーして、それを解凍し、含まれている実行ファイルを実行してから、インストーラを実行します。
データベース所有者(oracleなど)として、この項の手順を実行します。バンドルは一時ディレクトリにステージングしますが、バンドルを解凍し、含まれている実行ファイルを実行した後、インストール・パッケージは$ORACLE_HOMEの下のサブディレクトリにインストールされます。次に例を示します。$ORACLE_HOME/BDSJaguar-3.2.1/cdh510-6-node1.mycluster.mydomain.com
開始する前に、ORACLE_HOMEおよびORACLE_SIDが正しく設定されていることを確認してください。
コンポーネントのコピーおよびインストールの準備
まだそうしていない場合は、希望の方法を使用して、Hadoopクラスタ管理サーバーからOracle Databaseサーバーにデータベース側のインストール・バンドルをコピーします。バンドルが複数ある場合は、Oracle Databaseに接続するクラスタに適切なバンドルを選択してください。一時的なステージング領域として使用する任意の場所にそれをコピーします。コピー操作を実行する場合、Hadoopクラスタ管理サーバーにrootとしてログオンし、Oracle Big Data SQLインストール・ディレクトリ内のバンドルの場所に移動し、バンドルをデータベース・サーバーにプッシュする方法が簡単です。データベース側でのリモート・ログオンにデータベース所有者アカウント(通常はoracle)を使用します。
/opt/tmpにコピーされます。このバンドルはセキュアなディレクトリにコピーできますが、まず、ディレクトリが存在していることを確認してください。 # cd <Big Data SQL Install Directory>/BDSjaguar-3.2.1/db-bundles # scp bds-3.2.1-db-<cluster>-<yymmdd.hhmi>.zip oracle@<database_node>:/opt/tmp
データベース・リクエスト・キーを生成した場合は、そのキーもOracle Databaseサーバーにコピーします。
# cd <Big Data SQL Install Directory>/BDSjaguar-3.2.1/dbkeys # scp <database name or other name>.reqkey oracle@<database_node>:/opt/tmp
データベース・サーバー・ホストにoracle (またはデータベース所有者であるユーザー)としてログオンし、cdを使用して1つ以上のファイルをコピーしたディレクトリに移動します。
バンドルを解凍します。これには、単一の圧縮された実行ファイルが含まれています。
前提条件の環境変数($ORACLE_HOMEおよび$ORACLE_SID)が設定されていることを確認します。
$ORACLE_HOMEに解凍するためにファイルを実行します。次に例を示します。$ ./bds-3.2.1-db-cdh510-170309.1918.run
Oracle Databaseインスタンスと複数のHadoopクラスタ間に独立したOracle Big Data SQL接続を設定できるため、runコマンドは$ORACLE_HOME/BDSJaguar-3.2.1の下のクラスタ固有のディレクトリにバンドルを解凍します。次に例を示します。
$ ls $ORACLE_HOME/BDSJaguar-3.2.1 cdh510-6-node1.mycluster.mydomain.com test1-3-node1.myothercluster.mydomain.com
BDSJaguar-3.2.1ディレクトリがまだ存在しない場合は、そのディレクトリも作成されます。
データベース・リクエスト・キーを生成した場合は、新しく作成したインストール・ディレクトリにそれをコピーします。次に例を示します。
$ cp /opt/tmp/mydb.reqkey $ORACLE_HOME/BDSJaguar-3.2.1/cdh510-6-node1.mycluster.mydomain.com
ヒント:
また、キー・ファイルを一時的な場所に置いておき、そのキー・ファイルが存在する場所をスクリプトに指示するためにインストール・コマンドで--reqkeyパラメータを使用することもできます。このパラメータでは、デフォルト以外のリクエスト・キーのファイル名またはパス、あるいはその両方を指定できます。
ただし、インストール・スクリプトがインストール・ディレクトリ内のキーを検出するのは、キー・ファイル名がデータベース名と同じ場合のみです。それ以外の場合、キーがローカルであっても、異なる名前をキーに付けた場合には、インストール・スクリプトが識別できるように引き続き--reqkeyを使用する必要があります。
クラスタのインストール・ディレクトリを用意したら、Oracle Big Data SQLのすべてのデータベース側をインストールするための準備は完了です。
Oracle DatabaseノードでのOracle Big Data SQLのインストール
重要:
インストールの最後に、次のいずれかまたは両方の条件においてOracle Databaseの再起動が1回必要になることがあります。
Oracle DatabaseにOracle Grid Infrastructureが含まれていない場合。この場合、diskmonのスタンドアロン操作をサポートするために、インストール・スクリプトによってpfileまたはspfile構成ファイルが変更されます。
cellinit.oraに記録されているIPアドレスおよび通信プロトコルに変更がある場合。これらのパラメータは、Hadoopクラスタ上のセルへの接続を定義します。たとえば、これが再インストールで、Hadoop/Oracle Database接続のIPアドレスがイーサネット・アドレスからインフィニバンド・アドレスに変更されるか、プロトコルが(TCPとUDP間で)変更されるか、またはその両方の場合、データベースを再起動する必要があります。
データベースが実行中でない場合には起動します。
Oracle Databaseノードにoracleとしてログオンし、$ORACLE_HOME/BDSJaguar-3.2.1の下のクラスタ固有のインストール・ディレクトリに移動します。次に例を示します。
$ cd $ORACLE_HOME/BDSJaguar-3.2.1/cdh510-6-node1.my.domain.com
データベース側のOracle Big Data SQLインストーラであるbds-database-install.shを実行します。オプションのパラメータをいくつか含める必要がある場合があります。
$ ./bds-database-install.sh [options]
データベースを再起動します(オプション)。
関連項目:
bda-database-install.shインストーラ・コマンドは、通常はオプションですが構成によっては必須になるパラメータをサポートしています。「bds-database-install.shのコマンドライン・パラメータ・リファレンス」を参照してください
データベース認証またはHadoop Secure Impersonationを有効にした場合の追加のステップ
このインストール・バンドルの作成に使用される構成ファイルでdatabase_auth_enabledまたはimpersonation_enabledがtrueに設定されている場合、データベース側のインストーラによって生成されたZIPファイルをHadoopクラスタ管理サーバーにコピーし、Jaguarのデータベース確認応答操作を実行します。これで、HadoopクラスタとOracle Databaseの間のログイン認証の設定が完了します。
<name of the Hadoop cluster>-<number nodes in the cluster>-<FQDN of the node where the cluster management server is running>-<FQDN of this database node>.zip次に例を示します。
$ ls $ORACLE_HOME/BDSJaguar-3.2.1/cdh510-6-node1.my.domain.com/*.zip $ mycluster1-18-mycluster1node03.mydomain.com-myoradb1.mydomain.com.zip
ZIPファイルをHadoopクラスタ管理サーバーの/opt/oracle/DM/databases/confにコピーします。
クラスタ管理サーバーにrootとしてログオンし、Oracle Big Data SQLがインストールされたディレクトリの下の/BDSjaguar-3.2.1に移動し、databaseack (Jaguarのデータベース確認応答ルーチン)を実行します。インストール・バンドルの生成に使用された構成ファイル(bds-config.jsonなど)を渡します。
# cd <Big Data SQL Install Directory>/BDSjaguar-3.2.1 # ./jaguar databaseack bds-config.json
bds-database-install.shスクリプトには、多数のコマンドライン・パラメータを使用できます。各パラメータはオプションですが、このスクリプトには少なくとも1つのパラメータが必要です。
表3-1 bds-database-install.shのパラメータ
| パラメータ | 機能 |
|---|---|
--install |
このクラスタへのOracle Big Data SQL接続をインストールします。 注意: Oracle Big Data SQL 3.2以前のリリースでは、その他のパラメータが指定されていない場合、installコマンドが暗黙的に選択されます。リリース3.2では、このパラメータを明示的に指定してインストールを実行する必要があります。 |
--version |
bds-database-install.shスクリプトのバージョンを示します。 |
--info |
クラスタ名、クラスタ管理サーバー・ホスト、Webサーバーなど、クラスタに関する情報を表示します。 |
--grid-home |
Oracle Gridホーム・ディレクトリを指定します。 |
--crs |
Oracle Big Data SQL MTA extprocを設定するには、 --crs={true|false}
インストーラは、Gridが実行されているかどうかを常に検証します。Gridが実行されていない場合、インストーラはGridがインストールされておらず、データベースが単一インスタンスであると見なします。次に、
|
--cdb |
CDBデータベースのすべてのPDBにデータベース・オブジェクトを作成します。 --cdb={true|false}
|
--ip-cell |
複数のネットワーク・インタフェースがある単一インスタンス・データベース環境でdiskmonプロセスによって使用されるIPアドレス。 Oracle Exadata Database Machineでは無視されます。 --ip-cell=<IP address>
|
--db-resource |
非推奨。 Oracle Big Data SQLスクリプトは、 --db-resource=$ORACLE_SID |
--db-name |
非推奨。 Oracle Big Data SQLスクリプトは、 --db-name=$ORACLE_HOME |
--reqkey |
このパラメータは、リクエスト・キー・ファイルの名前と場所をインストーラに伝えます。データベース認証は、構成でデフォルトで有効になっています。この機能を有効にしない場合を除き、構成を完了する手順の1つとして、
リクエスト・キー・ファイル名をパスなしで指定した場合、キー・ファイルはインストール・ディレクトリにあるものと見なされます。ファイル名がデータベース名と同じである場合、インストーラはキーを探します。 たとえば、この場合、リクエスト・キー・ファイルはインストール・ディレクトリにあり、名前はデータベース名と同じです。 $ ./bds-database-install.sh --install このファイルは、最初のHadoopクラスタをデータベースに接続するためにデータベース側で1回のみ使用されます。同じデータベースに接続する後続のクラスタ・インストールでは、この構成されたキーが使用されます。 |
--uninstall |
このクラスタへのOracle Big Data SQL接続をアンインストールします。 |
--reconfigure |
bd_cellネットワーク・パラメータ、Hadoop構成ファイルおよびBig Data SQLパラメータを再構成します。 このクラスタに接続するためのOracle Big Data SQLインストールがすでに存在している必要があります。 Hadoopクラスタ側で変更(DataNodeインベントリの変更など)が行われた場合は、reconfigureを実行します。 |
--databaseack-only |
データベース確認応答zipファイルを作成します。(その後、Hadoopクラスタ管理サーバー上の |
--mta-restart |
MTA extprocが再起動します。(Oracle Big Data SQLがすでにデータベース・サーバーにインストールされている必要があります。) |
--mta-setup |
他に変更を加えることなく、MTA extprocを設定します。(Oracle Big Data SQLがすでにデータベース・サーバーにインストールされている必要があります。) |
--mta-destroy |
MTA extprocを破棄し、他に変更は加えません。(Oracle Big Data SQLがすでにデータベース・サーバーにインストールされている必要があります。) |
--aux-run-mode |
Oracle Big Data SQLは一般ユーザー(スーパーユーザー以外)としてデータベース側にインストールしているため、
--aux-run-mode=<mode>
モードのオプションは次のとおりです。
|
--root-script |
起動rootスクリプトの実行を有効または無効にします。
--root-script={true|false}
|
--no-root-script |
起動rootスクリプトの実行を無効にします。 |
3.1以前のOracle Big Data SQLリリースでは、アクセスはPUBLICユーザー・グループに付与されます。現在のリリースでは、Oracle Big Data SQLにアクセスする必要があるユーザーごとに次の処理を実行する必要があります。
BDSQL_USERロールを付与します。
BigDataSQL構成ディレクトリ・オブジェクトの読取り権限を付与します。
たとえば、user1にアクセスを付与するには、次のようにします。
SQL> grant BDSQL_USER to user1; SQL> grant read on directory ORACLE_BIGDATA_CONFIG to user1;
関連項目:
Hadoopデータへのアクセスを間接的にユーザーに提供するには、DBMS_BDSQL PL/SQLパッケージを使用します。このパッケージが実装しているマルチユーザー認可機能は、Hadoop Secure Impersonationを使用して、oracleアカウントを有効にし、他の指定のユーザーのかわりにタスクを実行できるようにします。