1. オーナーズ・ガイド
  2. ソフトウェアのインストールおよび構成
  3. Oracle Big Data Applianceソフトウェアのインストール

10 Oracle Big Data Applianceソフトウェアのインストール

この章では、Oracle Big Data Applianceのソフトウェアをインストール、再インストールおよび再構成する方法について説明します。この章の内容は次のとおりです。

注意:

Oracle Big Data Appliance構成生成ユーティリティで必要なパスワードを入力しなかった場合、ソフトウェアのインストール時に入力するように要求されます。オペレーティング・システムのrootおよびoracleユーザー、Cloudera Managerのadminユーザー、およびMySQL管理者の現在のパスワードを把握していることを確認してください。Oracle Big Data Connectorsをインストールまたは再インストールする場合、Oracle Data IntegratorのMySQLパスワードも必要です。

10.1 Mammothユーティリティについて

Mammothは、Oracle Big Data Applianceソフトウェアをインストールおよび構成するためのコマンドライン・ユーティリティです。Mammothを使用すると、次のことを実行できます。

  • CDHまたはOracle NoSQL Databaseのクラスタを設定できます。

  • 複数のラックにクラスタを作成できます。

  • Oracle Big Data Applianceのラックに複数のクラスタを作成できます。

  • 同じラックまたは新しいラックの新しいサーバーにクラスタを拡張できます。

  • 新しいソフトウェアでクラスタを更新できます。

10.1.1 ローリング・アップグレードについて

ローリング・アップグレードは、3つのレプリカのうち1つのノードを常にアクティブにするシーケンスでクラスタのノードを再起動します。これにより、クラスタは一連の再起動全体でオンラインのままになることができます。その結果、クラスタの一部の(すべてではない)サービスをアップグレード中に中断せずにアクセス可能なままにすることができます。

ローリング・アップグレードは、CDH 4.1以降を実行しているインストールでのみ使用できます。

ペアとなっているノードを順次に再起動するとプロセスの時間が長くなるため、ローリング・アップグレードは、すべてのサーバーが同時に再起動される従来のMammothアップグレードよりも長時間かかります。Mammothノードと(一度に再起動される)クリティカル・ノードごとに4分に加えて、非クリティカル・ノードのペアごとに平均8から10分を見積もってください。

ローリング・アップグレードは自動で実行できます。各サーバーのアップグレード後の再起動に成功した場合、再起動イベントは、あるサーバーから次(または次のペア)のサーバーに自動的に「ロール」します。サーバー再起動時に更新でエラーまたは警告条件が検出された場合、プロセスは一時停止し、続行するかどうかを確認するプロンプトが表示されます。 

Reboot of node mnode22bda08 had errors/warnings, do you wish to proceed anyway? [y/n]:

  • nを入力した場合:

    問題を解決できるようにアップグレードが停止します。

    準備ができたら、mammoth -pを使用してインストールを再開します。

  • yを入力した場合:

    アップグレードが続行されます。

このプロンプトは、ノード・アップグレードごとに1回表示されます。ノードがすでに再起動されている(そしてプロンプトに対してすでに回答されている)場合、プロンプトを再度表示せずにアップグレードが続行されます。

ローリング・アップグレードが可能な場合

ローリング・アップグレードは、このドキュメントで説明する次のアップグレード・タスクのオプションです。

通常、「クラスタへのサーバーの追加」では、このプロセスでクラスタ停止時間は発生しません。ただ1つの例外は、1ラック・クラスタが初めて2番目のクラスタに拡張されるケースで、クラスタ拡張のために停止時間が発生します(このときにマスターの役割が追加のラックに移されます)。ただし、その後のクラスタ拡張では停止時間は必要なくなります。

ローリング・アップグレードがオプションの場合、Mammothではコンソールに次のメッセージが表示され、インストールをローリング・アップグレードとして続行するかどうかの選択を求められます。

You can choose a rolling upgrade or continue with a conventional upgrade. Rolling upgrades need a minimum replication factor of three (this is the default in Mammoth) to have full availability during the upgrade. Do you wish to perform a Rolling Upgrade? [y/n]:

注意:

プロンプトにyと入力してローリング・アップグレードを受け入れた場合、クラスタはプロセスにコミットされ、クラスタ内のすべてのノードのアップグレードは中断なしで完了するまで続行する必要があります。

ローリング・アップグレード時のサービス可用性

ローリング・アップグレードでは、HDFS High Availability (HDFS HA)を使用するように構成されているサービスは、クラスタ内の各ノードがアップグレードされて再起動されるときに継続的に使用可能なままになります。これらには、HDFS、YARNおよびZookeeperが含まれます。これらのサービスをアップグレード中に使用可能にするには、3以上のHadoopレプリケーション係数が必要です。その理由は、ローリング・アップグレードはノードをペアで再起動するためです。グローバル構成は個々のファイルに対して上書きされている可能性があるため、アップグレードは、レプリケーション係数がこの最小値を満たすかどうかを事前に判断できません。不十分なレプリケーション係数でもアップグレードは停止されませんが、その場合、HDFS HA対応のサービスでダウンタイムが発生することがあります。

ローリング・アップグレードでは、Clouderaサービスは2つのバッチで再起動されます。これは、アップグレード中にHDFSおよびその他のサービスへのアクセスを維持するものです。HDFS HAを使用するように構成されない、または構成できないサービスは、レプリケーション係数に関係なく、ローリング・アップグレード中に使用不能になることがあります。

10.2 インストールの前提条件

Oracle Enterprise Managerオプションでは、Oracle Big Data Applianceと同じネットワークのリモート・サーバーにソフトウェアが必要です。Mammothを実行する前にそれらのインストールが完了している必要があり、そうでない場合は失敗します。

同様に、キー配布センター(KDC)がリモート・サーバーにインストールされている場合には、Kerberosに対してもいくつかのステップを完了する必要があります。Oracle Big Data ApplianceにKDCをインストールする場合、事前に行うステップはありません。

次の表では、すべてのインストール・オプションの前提条件について説明します。

自動サービス・リクエストの前提条件は、次のとおりです。

  • My Oracle Supportアカウントが設定されている。

  • ASRマネージャが正常に稼働している。

Enterprise Managerの前提条件は、次のとおりです。

  • Oracle Management System (OMS)バージョン12.1.0.4.0以上が正常に稼働している。

  • OMSエージェント・プルURLが動作している。

  • OMS emcliダウンロードURLが動作している。

  • HTTPSアップロード・ポートとコンソール・ポートの両方が開いている。

注意:

OMS資格証明を再確認し、Mammothの実行時に正確に入力してください。Enterprise Managerの検出プロセスの失敗の主な原因は、無効な資格証明です。

リモートKDCの場合のMIT Kerberosの要件:

  1. kadminから次のコマンドを実行し、cloudera-scm/adminをユーザーとしてKDCデータベースに追加します。 

    addprinc -randkey cloudera-scm/admin@<REALM NAME>

  2. cloudera-scm/adminに、Kerberosデータベースに対するすべての権限を付与します。データベースからプリンシパルを追加、修正、削除、リストできる必要があります。

  3. kadminから次のコマンドを実行して、cmf.keytabファイルを作成します。 

    xst -k cmf.keytab cloudera-scm/admin@<REALM NAME>

  4. cmf.keytabを/opt/oracle/BDAMammothに移動します。

  5. OozieとHueをサポートするには、リモートKDCが更新可能なチケットをサポートしていることを確認してください。サポートしていない場合には、次のステップを実行します。

    1. kdc.confを開き、max_lifeとmax_renewable_lifeの値を設定します。max_lifeパラメータはチケットが有効な期間を定義し、max_renewable_lifeパラメータはユーザーがチケットを更新できる期間を定義します。

    2. krbtgtプリンシパルのmaxrenewlifeを設定します。次のkadminコマンドを使用して、durationを所定の期間で置き換え、REALM NAMEをレルムの名前で置き換えます。 

      modprinc -maxrenewlife duration krbtgt/REALM NAME

    Kerberosを構成するとき、KDCが更新可能なチケットをサポートしない場合には、OozieとHueが正常に動作しないことがあります。

リモートKDCの場合のActive Directory Kerberosの要件

Active Directory Kerberosの要件は、MOS (My Oracle Support)に記載されています。

MOSドキュメント2013585.1および2029378.1を参照してください。

10.3 Mammothソフトウェア・デプロイメント・バンドルのダウンロード

Mammothバンドルには、インストール・ファイルが含まれます。ソフトウェアをインストールする前に、「構成ファイルの生成」の説明に従い、Oracle Big Data Appliance構成生成ユーティリティを使用して構成ファイルを生成する必要があります。

ラック・サイズや、CDHまたはOracle NoSQL Databaseクラスタを作成しているか、または既存のクラスタをアップグレードしているかにかかわらず、この章で説明されているすべての手順に同じバンドルを使用します。

注意:

Mammothソフトウェア・デプロイメント・バンドルには、ベース・イメージISOのコピーは含まれなくなりました。後からベース・イメージが必要になった場合は、次に示すMy Oracle Supportノートにダウンロード・リンクがあります: Oracle Big Data Appliance Patch Set Master Note (Doc ID 1485745.1)

Mammothバンドルをダウンロードするには、次の手順を実行します。

  1. My Oracle SupportまたはAutomated Release Updates (ARU)のいずれかのダウンロード・サイトを見つけます。

    My Oracle Support

    1. My Oracle Supportにログインし、『Oracle Big Data Appliance Patch Set Master Note (Doc ID 1485745.1)』を表示します。

    2. Mammothバンドルのリストから、このリリースのバンドル・ソフトウェア・バージョンのリンクをクリックします。

    3. 表から該当するMammothパッチ・バンドルへのリンクを見つけてください。

    ARU

    1. ARUに接続します。

    2. Patchesページで、「Product」にBig Data Appliance統合ソフトウェアおよび「Release」に適切なリリース番号を設定します。

    3. 「Search」をクリックします。

  2. BDA Mammoth ZIPファイルをクラスタの第1ノードの任意のディレクトリ(/tmpなど)にダウンロードします。ラックの構成に応じて、このノードはラックの下から数えて1番目、7番目または13番目のサーバーになる場合があります。マルチラック・クラスタの場合、このサーバーはプライマリ・ラックにあります。

    パッチは、p<patch_number>_Linux-x86-64_<file number>of<total number of files>.zipのラベルのファイルのセットで構成されます

  3. クラスタの第1ノードにrootとしてログインします。

  4. ダウンロードしたすべてのzipファイルからすべてのファイルを解凍します。次に例を示します。

    $ unzip p<patch_number>_Linux-x86-64_1of4.zip
	Archive:  p<patch_number>_<version>_Linux-x86-64_1of4.zip
  inflating: README.txt
   creating: BDAMammoth-ol7-<version>/
 ...

  5. BDAMammoth-<version>ディレクトリに移動します。 

    # cd BDAMammoth-ol7-<version>

  6. BDAMammoth-<version>.runからすべてのファイルを抽出します。 

    # ./BDAMammoth-ol7-<version>.run
 
Big Data Appliance Mammoth v<version> Self-extraction

Checking for and testing BDA Package in /tmp
 
Removing existing temporary files
 
Generating /tmp/BDAMammoth.tar
Verifying MD5 sum of /tmp/BDAMammoth.tar
/tmp/BDAMammoth.tar MD5 checksum matches
 
Extracting /tmp/BDAMammoth.tar to /opt/oracle/BDAMammoth
 
Extracting Package RPMs to bdarepo
Moving BDAPackages into /opt/oracle/

Extracting BDA Extras
 
Removing temporary files
     .
     .
     .
Please "cd /opt/oracle/BDAMammoth" before running "./mammoth -i <rack_name>"
#

    Mammothソフトウェアの新規バージョンは/opt/oracle/BDAMammothにインストールされ、以前のバージョン(アップグレードの場合)は/opt/oracle/BDAMammoth/previous-BDAMammothに保存されます。

  7. 実行中のインストール・タイプに固有の手順に従います。

10.4 新規ラックへのソフトウェアのインストール

Mammothでは、Oracle Big Data Appliance構成生成ユーティリティによって生成されたファイルを使用して、Oracle Big Data Applianceにソフトウェアをインストールして構成できます。クラスタは、CDH (Hadoop)専用またはOracle NoSQL Database専用にできます。

CDHクラスタの場合、MammothによってCloudera's Distribution including Apache Hadoopのインストールと構成が行われます。これには、すべてのHadoopソフトウェアおよびCloudera Manager (Hadoopクラスタを管理するためのツール)が含まれます。ライセンスがある場合、MammothはオプションでOracle Big Data Connectorsのすべてのコンポーネントをインストールおよび構成できます。

NoSQLクラスタの場合、MammothはOracle NoSQL Databaseをインストールします。Oracle Big Data Appliance 2.2より、CDHとOracle NoSQL Databaseはクラスタを共有しません。

Mammothでは、ラック内のすべてのサーバー全体にソフトウェアをインストールする以外に、必要なユーザー・アカウントの作成、適切なサービスの開始、および適切な構成パラメータの設定を行うことができます。この完了時には、完全に機能する高度にチューニングされたHadoopクラスタを実行できます。

10.4.1 ソフトウェアのインストール

次の手順に従って、1つ以上のOracle Big Data Applianceラックにソフトウェアをインストールして構成します。単一のインストールで複数のラックに1つのクラスタを構成できます。

ソフトウェアをインストールするには、次の手順を実行します。

  1. Oracle Big Data Applianceラックが/opt/oracle/bda/network.json (またはcluster-network.json)に記述されたカスタム・ネットワーク設定に従って構成されていることを確認します。ラックがまだ工場出荷時のデフォルトIPアドレスに構成されている場合、最初に「ネットワークの構成」のステップに従ってネットワーク構成を実行します。

  2. ソフトウェアがまだラックにインストールされていないことを確認します。ソフトウェアがインストールされており、アップグレードする場合は、ステップ6でmammoth -pオプションを使用します。

  3. Mammothバンドルをダウンロードして解凍します。クラスタの第1サーバーにrootとしてログインする必要があります。

  4. BDAMammothディレクトリに移動します。 

    # cd /opt/oracle/BDAMammoth

  5. cluster_name-config.jsonを現在のディレクトリにコピーします。

  6. 適切なオプションを使用してmammothコマンドを実行します。次のサンプル・コマンドでは、すべてのステップが実行されます。 

    ./mammoth -i rack_name

    ベース・イメージのアップグレードが行われた場合、Mammothのインストール・ステップ3の完了後に、再起動するように要求されます。

  7. 自動サービス・リクエストのサポートをインストールした場合は、「自動サービス・リクエストのインストールの確認」のステップを実行します。

  8. サーバー上の別のCDHクラスタを構成するには、次の手順を実行します。

    1. BDAMammoth ZIPファイルをクラスタの第1サーバーの任意のディレクトリにコピーします。これは、サーバー7かサーバー13のいずれかです。

    2. ステップ3から7を繰り返します。各クラスタには独自のcluster_name-config.jsonファイルがあります。Oracle Big Data Appliance構成生成ユーティリティが、クラスタの名前に合わせて異なるディレクトリにファイルを作成します。

関連項目:

注意:

Mammothは、現在の構成を/opt/oracle/bda/install/stateディレクトリに格納します。このディレクトリのファイルは削除しないでください。クラスタにラックを追加するなど、Mammothをもう一度使用する必要がある場合に、この情報が不足していると実行が失敗します。

自動サービス・リクエストのインストールの確認

  1. My Oracle Support (http://support.oracle.com)にログインします。

  2. ドキュメントID 2103715.1のエンジニアド・システムASR構成チェック・ツール(asrexacheckバージョン4.x)に関するドキュメントを検索し、asrexacheckスクリプトをダウンロードします。

    本来、これはOracle Exadata Database Machineに対して実施するチェックですが、現在はOracle Big Data Applianceでもサポートされています。

  3. asrexacheckをOracle Big Data Applianceクラスタのサーバーにコピーします。

  4. rootとしてそのサーバーにログインします。

  5. asrexacheckをクラスタ内のすべてのサーバーにコピーします。 

    # dcli -C -f asrexacheck -d /opt/oracle.SupportTools

  6. ファイルのアクセス権限を変更します。

    # dcli -C chmod 755 /opt/oracle.SupportTools/asrexacheck

  7. スクリプトを実行します。

    # dcli -C /opt/oracle.SupportTools/asrexacheck

  8. Oracle Supportのリクエスト(SR)を保存してASRインストールを検証します。次の選択項目に注意してください。

    1. 「What is the Problem?」の「Hardware」タブをクリックします。

    2. 「Products Grouped By」で、「Hardware License」を選択します。

    3. 「Problem Type」で、「My - Auto Service Request (ASR) Installation and Configuration Issues」を選択します。

    4. asrexacheckの出力を含みます。

  9. 前のステップのセット(ソフトウェアをインストールするには、次のステップを実行します。)に戻り、ステップ8から続行します。

関連項目:

10.5 インストール中にエラーが発生した場合の対処方法

Mammothユーティリティが失敗した場合は、次のステップを実行して問題を解決します。

  1. エラー・メッセージを読んで、原因または解決策が示されているかどうかを確認します。
  2. 推奨される変更を行い、ステップを再実行します。
  3. エラー・メッセージに解決策が示されていない場合、または問題が解決されない場合:

    • My Oracle Supportでサービス・リクエスト(SR)を送信します。

    • エラー発生時にMammothにより生成された診断情報ZIPファイルをアップロードします。

関連項目:

『Oracle Big Data Applianceソフトウェア・ユーザーズ・ガイド』

10.6 クラスタへのサーバーの追加

サーバーを既存のクラスタに追加するには、Mammothユーティリティを使用してクラスタを新しいサーバーに拡張します。この目的にはOracle Big Data Appliance構成生成ユーティリティを使用しないでください。

クラスタの各ラックで、ラックがクラスタに提供できる最小サーバー数は3です。したがって、3サーバー以上を含む1つのグループを最初に追加する必要があります。最小の数を満たせば、その他の制限はありません。この後、ラックからクラスタに1つずつサーバーを追加することも、任意の数をまとめて追加することもできます。また、ラック上のすべてのサーバーにクラスタを同時に拡張することもできます。

同じラック(および同じクラスタ)にサーバーを追加すると、そのプロセスでクラスタの停止時間は発生しません。1ラック・クラスタが初めて2番目のクラスタに拡張されるとき、クラスタ拡張のために停止時間が発生します(このときにマスターの役割が追加のラックに移されます)。ただし、その後のクラスタ拡張では停止時間は必要なくなります。

新しいノードを既存のクラスタに追加する場合、エッジ・ノードをデコミッションする必要はありません。

新しいサーバー・ノードと古いサーバー・ノードの構成方法に大きな違いはありません。ただし、新しいノードのディスク容量が大きい場合、作成されるデータ・パーティションは、ディスク全体を使用するために対応して大きくなります。データ・ノードごとに使用可能な容量が異なる状況はHDFSによって処理されます。Oracle Big Data Applianceにより特別な構成が追加で実行されることはありません。

関連項目:

クラスタの追加サーバーにソフトウェアをインストールするには、次の手順を実行します。

作業を開始する前に:

  1. すべてのサーバーで同じソフトウェア・バージョンが実行されていることを確認します。追加のサーバーは、既存クラスタより新しいOracle Big Data Applianceベース・イメージを持つことはできません。

  2. 単一のHadoopクラスタを構成するすべてのラックがケーブルで接続されていることを確認します。

  3. rootとしてプライマリ・ラックのnode01に接続し、BDAMammothディレクトリに移動します。 

    cd /opt/oracle/BDAMammoth

    注意: Mammothは常にプライマリ・ラックから起動してください。

  4. サーバー・グループのパラメータ・ファイルを生成します。次の例では、ノード13から数えて6つのサーバーを追加します。

    ./mammoth -e node13 node14 node15 node16 node17 node18

    同じラックまたは複数のラックにあるサーバーを指定できます。

    ベース・イメージのアップグレードが行われた場合、Mammothのインストール・ステップ3の完了後に、再起動するように要求されます。

  5. Oracle Enterprise Manager Cloud Controlを使用してOracle Big Data Applianceを監視している場合、再検出を実行してハードウェアおよびソフトウェアの変更を特定します。

Oracle Big Data Connectorsのライセンスを持っている場合、それらはプライマリ以外のラックのすべてのノードにインストールされます(ただし、そこではサービスは実行されません)。Oracle Data Integratorエージェントは、引き続きプライマリ・ラックのnode03で実行されます。

Mammothは、/opt/oracle/bda/install/stateに格納されたファイルから現在の構成を取得します。これらのファイルが存在しないか、サービスのいずれかが手動で移動されて他のノードで実行されていると、Mammothは失敗します。

関連項目:

ソフトウェア・バージョンの違いについて

1つのHadoopクラスタとして構成されたすべてのサーバーには、同じイメージが存在する必要があります。新しいOracle Big Data Applianceラックには、以前にインストールされたラックと比較して新しいベース・イメージが工場出荷時にインストールされている可能性があります。任意のサーバーでimageinfoユーティリティを使用して、イメージ・バージョンを取得してください。単一のHadoopクラスタのすべてのサーバーに同じイメージ・バージョンが存在する場合、ソフトウェアをインストールできます。

新しいサーバーをHadoopクラスタの残りと同期するには、既存のクラスタを最新のイメージ・バージョンにアップグレードするか、新しいサーバーのイメージ・バージョンをダウングレードします。

イメージ・バージョンをアップグレードするには、次の手順を実行します。

イメージ・バージョンをダウングレードするには、次の手順を実行します。

  • 新しいラックのイメージを、クラスタにインストールされている古いバージョンに変更します。My Oracle Support情報センターID 1445745.2を参照してください。

  • 既存のクラスタの第1サーバーにある古いバージョンのMammothユーティリティを使用して、クラスタを新しいラックに拡張します。

新しいサーバー・モデルを追加する場合には、ダウングレードできるのは、そのモデルで使用可能な最初のソフトウェア・バージョンまでです。たとえば、Sun Server X3-2Lサーバーを追加する場合には、Oracle Big Data Applianceソフトウェアのバージョン2.3以上をインストールする必要があります。

10.7 Oracle Big Data Applianceでのソフトウェアのアップグレード

ソフトウェアをアップグレードする手順は、あるメジャー・リリースから別のメジャー・リリースにアップグレードする場合でも、単にパッチ・セットを適用する場合でも同じです。また、この手順は、Hadoopクラスタが1つのOracle Big Data Applianceラックで構成されていても、複数のラックで構成されていても同じです。

このプロセスによって、ファームウェア、オペレーティング・システム、Oracle Linux Unbreakable Enterprise Kernel (UEK)、CDH、JDKおよびOracle Big Data Connectors (事前にインストールされている場合)を含むソフトウェア・スタックのすべてのコンポーネントがアップグレードされます。

Oracle Big Data Connectorsのみをアップグレードして、ソフトウェア・スタックの他のコンポーネントをアップグレードしない場合は、Oracle Supportにサポートを依頼してください。

ソフトウェアのダウングレードはサポートされません。

注意:

アップグレードにより、ローリング・アップグレードを選択するか、従来のアップグレードを続行するかを確認するプロンプトが表示されます。従来のアップグレード・プロセスは、サービスを自動的に停止し、必要に応じて開始します。したがって、mammothコマンドの実行中はクラスタを使用できません。ローリング・アップグレードの利点は、アップグレード・プロセス全体を通じて一部のサービスに中断なくアクセスできることです。ただし、ローリング・アップグレードはサーバーの再起動が同時に行われないため、サーバーごとに時間が余分にかかります。

高可用性Sentryを含まないリリースからアップグレードする場合、ローリング・アップグレードを選択したか従来のアップグレードを選択したかに関係なく、SentryのHAを有効にするにはすべてのSentry依存サービスを短時間停止する必要があることを通知するメッセージがMammothにより表示されます。プロンプトが表示されたときにローリング・アップグレード・オプションを選択することもできますが、ローリング・アップグレードでは、Sentryおよび関連サービスの十分な可用性を維持することはできません。

現在、Oracle Big Data Applianceソフトウェアをアップグレードしても、対応するInfiniBandまたはCiscoスイッチのアップグレードは必要ありません。

10.7.1 オペレーティング・システムのバージョンについて

Oracle Big Data Appliance 4.13では、新規インストールでのOracle Linux 7、およびアップグレードでのOracle Linux 6がサポートされています。Oracle Linux 5はサポートされていません。

10.7.2 ソフトウェアのアップグレード

次の手順に従って、Oracle Big Data Applianceクラスタのソフトウェアを現在のバージョンにアップグレードします。

10.7.2.1 前提条件

Mammothユーティリティによってパスワードが求められた場合、クラスタで現在有効な次のパスワードが必要です。

  • oracle

  • root

  • Cloudera Manager admin

  • MySQL Database admin

  • Oracle Data IntegratorのMySQL Database (Oracle Data Integratorエージェントがインストールされている場合)

Oracle Big Data Appliance 4.1では、Apache SentryはファイルベースのプロバイダからSentryサービスへ変更されました。クラスタをアップグレードするときにファイルベースのプロバイダとしてのSentryが有効であった場合、ファイルベースのプロバイダが維持されます。Sentryサービスへ切り替えるには、ソフトウェアをアップグレードする前にSentryを無効にし、後でSentryを再び有効にします。

10.7.2.2 現在のソフトウェア・バージョンへのアップグレード
アップグレード前にクラスタ・サービスの状態が正常であることを確認します。特にリブート後が非常に重要です。 これはローリング・アップグレードの際にはさらに重要です。 ローリング・アップグレード時に、前のエラーが存在しているとパーセルのアップグレードが停止します(パーセルがすでにアップグレードされている場合でも)。 これによってサービスが起動できなくなります。再開するために手動のステップが必要になります。

次のようにOracle Big Data Applianceソフトウェアを現在のソフトウェア・バージョンにアップグレードします。これはサマリーです。次のステップの詳細、既知の問題および前提条件は、My Oracle SupportのDoc ID 2101906を参照してください。

重要:

アップグレードの前にすべてのOozieジョブを停止してください。そうしないとアップグレードが失敗することがあります。

アップグレードで、Spark 2はまだ存在しないクラスタに自動的にデプロイされます。

  1. 「Mammothソフトウェア・デプロイメント・バンドルのダウンロード」の説明に従って、Mammothバンドルをダウンロードして解凍します。プライマリ・ラックのノード1にrootとしてログインする必要があります。
  2. BDAMammothディレクトリに移動します。
    # cd /opt/oracle/BDAMammoth
  3. -pオプションを使用してmammothコマンドを実行します。
    # ./mammoth -p

    必要に応じて、Mammothによりベース・イメージが自動的にアップグレードされます。

  4. すべてのノードがリブートした後で、次のチェックを実行します。
    1. 稼働時間をチェックします。
      # dcli -C uptime
    2. /root/BDA_REBOOT_SUCCEEDEDをチェックします。
      # dcli -C ls -ltr /root/BDA_REBOOT_SUCCEEDED
      注意: BDA_REBOOT_SUCCEEDEDがない場合は、/root/BDA_REBOOT_*と/root/bda_reboot_statusをチェックします。
    3. カーネルとJDKがアップグレードされていることを確認します。
      # dcli -C uname -a 
# dcli -C java -version
    4. すべてのCloudera Configuration Managerサービスが正常であることをチェックします。場合によってはいくつかのサービスを手動で再起動する必要があります。

      注意:

      あらゆるアップグレード、特にローリング・アップグレードでは、続行するためにリブート後にCMのすべてのサービスが正常であることが重要です。 続行できないとアップグレードが失敗します。
  5. リブートとリブート後のチェックの後で、プライマリ・ラックのノード1にログインして、アップグレードを再開するためにmammoth -pを再び実行します。
    # cd /opt/oracle/BDAMammoth
# ./mammoth -p
  6. アップグレードが完了したら、MOSドキュメント(2101906.1)の説明に従ってアップグレード後の検証ステップを実行します。
10.7.2.3 個別パッチ・メカニズムを使用しないパーセルのアップグレードの実行

当然のことながら、Oracle Big Data Applianceソフトウェア用のOracleの個別パッチはサポートされています。 個別パッチの一環として行われないパーセルのアップグレードは、Oracleサポートの承認がないかぎり、サポートされません。

Mammothバンドルには、Cloudera's Distribution including Apache Hadoop (CDH)のパーセルの最新のバージョンが含まれています。ただし、CDHはClouderaのスケジュールに合わせてリリースされており、現在のMammothバンドルよりも新しいCDHのリリースが利用できる場合があります。新しいバージョンのCDHが、現在のOracle Big Data Applianceリリースとの統合のためにサポートされている可能性があります。疑問がある場合は、Oracleサポートに問い合せてください。

10.8 Oracle Linux 6からOracle Linux 7への移行

既存のOracle Linux 6クラスタをX7-2Lサーバーで拡張する場合は、Oracle Linux 7にクラスタをアップグレードすることを検討してください。新しいX7-2Lサーバーは、出荷時にOracle Linux 7がインストールされています。Oracle Linux 6クラスタはOracle Linux 7ノードをサポートしません。

このアップグレードはCDHクラスタ専用です。Oracle NoSQL Databaseクラスタには適用されません。

注意:

  • クラスタは、Oracle Linux 7への移行を開始する前に、Oracle Big Data Appliance v4.13.0-ol6である必要があります
  • このプロセスでは、Oracle Big Data Discoveryノードの移行はサポートされていません。移行前にOracle Big Discoveryを削除する(bdacli bdd disable)必要はありますが、移行後にリストアできます(bdacli bdd enable)。既存のOracle Big Data Discoveryデータを残したい場合は、無効化する前にデータをバックアップしておき、Oracle Big Data Discoveryを再有効化した後でデータをリストアしてください。

オペレーティング・システムの移行には3つのパッチが必要

  1. 更新したOracle Big Data Appliance Mammoth v4.13.0 for Oracle Linux 7。

    https://support.oracle.com/epmos/faces/PatchDetail?patchId=28675288

  2. Oracle Big Data Applianceベース・イメージv4.10.0-10 (以降) for Oracle Linux 7。このバージョンには、Oracle Linux 6からの移行のサポートが含まれています。

    https://support.oracle.com/epmos/faces/PatchDetail?patchId=28218768

  3. 最新のOracle Big Data Appliance RPM for Oracle Linux 7。

    https://support.oracle.com/epmos/faces/PatchDetail?patchId=29154804

移行に必要な時間の見積り

クラスタ全体のOracle Big Data Appliance Mammothアップグレードを実行してから、ノードごとにOSを移行する時間の合計が長くなる可能性があります。主な要因は、クラスタのサイズと、ノードのサーバー・モデルです。

スレーブ・ノードの場合、移行には3時間から4時間かかる場合があります。マスター・ノードの場合、MySQLデータベースのサイズ次第で、プロセスに5時間以上かかる場合もあります。

複数のノードの同時移行について

一度に複数のクリティカル・ノードを移行することはできません。(クリティカル・ノードはノード0からノード3です)。

この制約を使用して、クリティカルでない2つのノードを同時に移行することは可能です(3つ以上は不可)。

  • 移行されるノードの最初のペアについては、最初のノードでbdarestorenode.shの実行を完了してから、2番目のノードでbdarestorenode.shの実行を開始する必要があります。

一般的に、クラスタ内でbdarestorenode.shを同時に複数回実行しないことをお薦めします。ただし、bdadumpnode.sh、bdareimagenode.shを実行し、プロセス内の他のステップを2つの非クリティカル・ノードに対して同時に実行することはできます。

注意:

アップグレードの進行中、一部のノードはOracle Linux 7で実行され、その他のノードはOracle Linux 6で引き続き実行されます。この期間はクラスタの使用を継続しても安全です。ただし、アップグレードの進行中は、新しいサービスをクラスタに追加しないでください。

10.8.1 重要な考慮事項

アップグレードを開始する前に知っておく必要がある事項を次に示します。

OSアップグレードでは最新のOracle Big Data Applianceベース・イメージが使用される

Oracle Linux 7の最新のOracle Big Data Applianceベース・イメージ(4.10.0-10以上)を、各ノードに直接ダウンロードするか、各ノードにイメージをコピーできるクラスタ内の場所にダウンロードする必要があります。この手順では、各ノードにベース・イメージを解凍しますが、インストールしないでください。OSのアップグレードでは、ベース・イメージで使用可能な機能の一部を利用します。

Mammothでインストールされたソフトウェアのみ移行される

OSアップグレード・プロセスではバックアップが実行されず、Mammothによってインストールされなかったソフトウェアは移行されません。

Mammothインストール・メカニズム以外のサード・パーティ・ソフトウェア製品をインストールしている場合は、アップグレード後に、バックアップとリストア、またはそれらのソフトウェアの再インストールを個別に準備する必要があります。これには、MammothによってインストールされないOracleソフトウェアと、Clouderaソフトウェア(Kudu、Kafka、Sparkなど、便宜上Mammothソフトウェア・デプロイメント・バンドルに含めることができるが、Mammothによってインストールされないソフトウェア)が含まれます。

また、ユーザーによってOracle Linux 6カーネルに追加されるOracle Linuxモジュールは、Oracle Linux 7インストールに移行されません。

ファイルのバックアップに関する考慮事項

このプロセスでは、バックアップする重要なファイルのリストが生成されます。独自のリストを追加することもできます。

HDFSデータはアップグレードで維持されます。

移行の前に保存する必要のある非HDFSデータを個別にバックアップするのはお客様の責任です。HDFSに格納されていないすべてのファイルをバックアップすることをお薦めします。

アップグレード中のサービスの中断

重要なノード(一般にはノード0 - 3)のアップグレードでは、重要なサービスを必ず一時的に中断する必要がありますが、どの時点でもクラスタ全体がシャットダウンされることはありません。進行中のジョブは引き続き実行できます。Hadoop機能は部分的に残されるか、大部分を使用できます。プロセスのどの時点でサービスが停止されるかは、現在アップグレードを実行中のノードで実行されているサービスとロールによって異なります。

Oracle Big Data Applianceでのデータの3要素レプリケーションにより、重要性の低いノード(主にデータを格納するノード)のアップグレード中に、サービスが失われることはありません。クラスタでレプリケーション係数が3 (デフォルト)に設定されていることを確認します。そうでない場合は、アップグレードを実行中のノードのデータを一時的に使用できなくなる場合があります。

1ラック・クラスタとマルチラック・クラスタのノード全体のサービスとロールの分散には、いくつかの違いがあります。ノードでアップグレードを実行中に、ノードで実行中のサービスを使用できない場合は、クラスタのノードでアップグレードをどのように指定し、スケジュール設定しているかに原因がある可能性があります。これ以外は、1ラック・クラスタとマルチラック・クラスタのアップグレード・プロセスで特別な考慮事項はありません。

セキュリティ設定は維持される

Kerberosセキュリティ構成とHDFS透過的暗号化およびHTTPS/ネットワーク暗号化はアップグレードで保持されます。

Cloudera Managerのロールはアップグレードで維持されます。

各ノードのアップグレード後にヘルス・チェックを実行し、必要に応じて負荷をリバランス

各ノードでアップグレードが完了した後、クラスタ状態を再チェックし(mammoth -c)、Cloudera Manager Webコンソールを使用してサービスのヘルス・ステータスを再チェックします。

OSアップグレード中、アップグレードされているノードのHDFSデータは他のノードに自動的にレプリケートされます。レプリケートされたデータを受け取るノードの負荷がすでに高い場合、CMでは、レプリケーションが一部のDataNodeロールに対して心配な状態であることを示す黄色のインジケータをトリガーすることがあります。

この状況が発生した場合、次のアップグレードに進む前にCMでHDFS Balancerを実行してください。黄色の警告インジケータの原因が過度の利用である場合は、リバランスによってその原因を消去する必要があります。

  1. 構成マネージャで、HDFSサービスに移動します。

  2. 「Actions」を選択した後、「Rebalance」を選択します。

  3. 「Rebalance」をクリックして続行します。

注意:

データ・ボリュームによっては、リバランスに長時間かかる場合があります。

Oracle Big Data Connectorsを有効にすると、アップグレード後にORAAHが機能しないことがある

これを解決するには、アップグレード後にOracle Big Data Connectorsを無効にしてから再度有効にします。どちらの操作でも、構成マネージャの管理パスワードと、MySQLルート・パスワードを使用して認証する必要があります。 

# bdacli disable bdc
# bdcali enable bdc

Big Data Connectorsを無効化すると、ODIエージェントも無効化されます。ODIエージェントも再度有効にする場合は、次のプロンプトでyと入力します。 

Do you wish to enable ODI? [y/n]: y

ノードのイメージ変更中に発生するエラー

  • bdareimagenode: Preparing internal USB disk failed

    このエラーが表示された場合は、次のようにします。

    1. ノードを再起動します。
    2. lsscsiを実行し、ディスクが正しい順序であることを確認します。
    3. mount -l を実行して、マウント済のHDFSパーティションを確認します。異常がないかどうか確認します。
    4. ノードのイメージ変更を繰り返します。
      # ./bdareimagenode.sh | tee /path_to_log/bdareimagenode.log
  • cp: writing `/tmp/bdausbmnt/boot/upgrade.img': No space left on device

    4 GBのUSBドライブでサーバーをイメージ変更する場合、このエラーはログ・ファイルbdareimagenode-prepare-usb.outに記録されます。これは予想範囲のエラーで問題はないため、無視できます。upgrade.imgファイルおよびそれ以降のすべてのファイルは、イメージ変更処理によって不要となります。

10.8.2 Oracle Linux 7への移行の前提条件

移行に進む前に、これらの前提条件が満たされていることを確認してください。

  • クラスタのソフトウェア・レベルは、Oracle Big Data Appliance 4.13.0以上ではOracle Linux 6である必要がある

  • ODI (Oracle Data Integrator)の無効化

    Oracle Big Data Connectorsとは別にODIエージェントのみを無効にするbdacliコマンドはありません。ODIエージェントを無効にするには、次のようにOracle Big Data Connectorsを無効にします。 

    # bdacli disable bdc

    アップグレード後にbdacli enable bdcを使用してOracle Big Data Connectorsをリストアできます。ODIエージェントを再インストールするかどうかを選択するように求められます。

  • Oracle Big Data SQLの無効化またはアンインストール

    Oracle Big Data SQLがインストールされている場合、ノードでOSアップグレードを実行する前に、インストールのHadoop側をアンインストールする必要があります。インストールのデータベース・サーバー側をアンインストールする必要はありません。HadoopクラスタでOSアップグレード中にデータベース側は影響を受けませんが、アップグレードの進行中、Big Data SQLクラスタを再度有効にするまでは、Hadoopのデータに対する問合せは機能しません。

    • Oracle Big Data SQL 3.2以降の場合は、次のbdacliコマンドを使用して、クラスタ全体でこのOracle Big Data SQLを無効にします。

      # bdacli disable big_data_sql

    • 以前のバージョンのOracle Big Data SQLがインストールされている場合は、uninstallパラメータ、およびインストールの実行に使用した構成ファイルと同じバージョンの構成ファイルを指定したsetup-bdsコマンドを使用します。 

      # ./setup-bds uninstall bds-config.json

    ヒント:

    使用する方法がわからない場合、安全なのはbdacli disable big_data_sqlを試行することです。このコマンドが失敗した場合、 ./setup-bdsを使用してソフトウェアがインストールされた可能性があります。

    OSアップグレードの前に、Oracle Big Data SQLを削除していない場合、Oracle Big Data SQLを削除する必要がある旨のメッセージがプロセスで表示され、エラーで終了します。

    アップグレード後に、Big Data SQLをHadoopクラスタに再インストールし、インストールのデータベース側と再接続します。HadoopクラスタにOracle Big Data SQLを再インストールした後に接続の問題が発生した場合は、データベース・サーバーでインストールの再構成を試み、2つの側を再度整合させることができます。『Oracle Big Data SQLインストレーション・ガイド』の./bds-database-install.sh --reconfigureに関する項を参照してください。

  • eCryptfsが使用されている場合はアンインストールする

    古いバージョンのOracle Big DataではeCryptfsの使用がサポートされていましたが、この暗号化メソッドのサポートは後続のバージョンで非推奨になりました。eCryptfs暗号化を使用するノードのアップグレードはサポートされていません。

    eCryptfsを削除していない場合、OSをアップグレードすると、それらを削除する必要がある旨のメッセージが表示され、エラーで終了します

    移行の前または後に、HDFS透過的暗号化を使用してデータを再暗号化できます。

    HDFS透過的暗号化およびHTTPS/ネットワーク暗号化はOSアップグレードの影響を受けません。

10.8.3 Oracle Linux 6からOracle Linux 7への移行ステップ

これはクラスタをOracle Linux 6からOracle Linux 7にアップグレードする手順です。

まだ確認していない場合は、この章の前の2つの項を確認してください。

再起動ステップの前に別のノードに重要な情報を保存するための要件には特に注意してください。

  1. rootとしてmammoth -cを実行し、クラスタの健全性をチェックします。先に進む前に、オペレーティング・システムのアップグレードに支障をきたす可能性のある問題を解決します。
  2. クラスタのロールが/opt/oracle/bda/install/state/config.jsonに適切に定義されていることを確認します。必要な変更を加え、すべてのクラスタ・ノードにconfig.jsonファイルを伝播します。

    # dcli -C -f /opt/oracle/bda/install/state/config.json -d /opt/oracle/bda/install/state/

  3. Mammothノード(Mammothを実行する、通常はクラスタの最初のノード)で、パッチ28675288 (Oracle Linux 7のOracle Big Data Appliance Mammoth v4.13.0デプロイメント・バンドル)をダウンロードします。これを/tmpに保存し、解凍します。
  4. Mammothノードで、RPMパッチ29154804をダウンロードします。パッチを/rootにコピーし、zipファイルからbda-4.13.0-5.el7.x86_64.rpm (のみ)をこのディレクトリに抽出します。
  5. BDAMammothディレクトリに移動し、BDAMammoth*.runをosupgradeフラグを指定して実行します。次に例を示します。
    # ./BDAMammoth-CDH-ol7-4.13.0.run -osupgrade
  6. クラスタの各ノードで、次のステップを実行します。一度に1つのノードで作業します。重要ではないDataNode (通常はNode4以降)から開始します。最後はMammothノード(通常はNode0)です。これは最も重要なノードです。
    1. Mammothによって管理されていないサービスの一部であるHadoopロールを削除します。Mammothによって管理されるサービスは、HDFS、Impala、Spark、Spark 2、YARN、Hive、HUE、OozieおよびZookeeperです。
    2. パッチ28218768をダウンロードします。これには、Oracle Big Data Applianceのベース・イメージが含まれています。アーカイブを/rootに解凍します。
    3. /root/<BDABaseImageVersion>/osupgrade_filelist内のすべてのファイルを確認します。これらは、アップグレードで事前に判断して保存する必要があるファイルおよびディレクトリです。ファイルまたはディレクトリをさらに保存する場合は、/opt/oracle/BDAMammoth/bdaconfig/tmp/my_filelistに独自のファイル・リストを作成します。
    4. 解凍したBDABaseImageディレクトリに移動します。そこから./bdadumpnode.shを実行します。
    5. bdadumpnode.shの出力で、使用するバックアップ・ディレクトリ・パスを検索します。メッセージBackup directory selectedのすぐ後にこれが表示されます。バックアップ・ディレクトリを書き留めます。これは、これらのステップで後から必要になります。
    6. 解凍したBDABaseImageディレクトリから、# ./bdareimagenode.shを実行します。これも出力をログに保存します。
      # ./bdareimagenode.sh | tee /path_to_log/bdareimagenode.log
      また、/tmp/bdareimagenode-prepare-usb.outをチェックし、スクリプトがエラーなしで実行されたことを確認します。
    7. 次のステップで再起動する前に、次の操作を行って重要な情報を保存します。

      注意:

      データ損失のリスクを軽減するには、次の手順を実行することを強くお薦めします。

      1. ラベル「DO_NOT_WIPE」が/dev/sda4に設定されていることを確認します。設定されていない場合は、次のコマンドで設定します。 

      e2label /dev/sda4  DO_NOT_WIPE
      2. 次の情報を現在のノード以外の場所に保存します。

      ヒント:

      デフォルトの3要素レプリケーションではこの情報が他の2つのノードにも自動的にコピーされるため、別のHadoopノードのHDFS内にこの情報を格納することをお薦めします。(HDFS外に情報を格納する場合、このレプリケーションによる特別な保護は受けられません。)

      • bdadumpnode.shの完了後の/u*/osupgrade_backupディレクトリ全体のバックアップ・コピー。

        ローカルの/opt/oracle/BDAMammoth/bdaconfig/tmp/my_filelistに同じディレクトリを含めることに加えて、これを行います。両方のステップを実行することで、さらに保護が強化されます。osupgrade_filelistまたはmy_filelistに保存されていないすべてのディレクトリは削除され、保存されません

      • 前のステップのbdadumpnode.shおよびbdareimagenode.shの出力のログ。
      • 次に示すblkid、df -hおよびlsblkコマンドの出力のバックアップ。
        # blk > <nodename>_blk.log
        # df -h > <nodename>_df-h.log
        # lsblk --output NAME,MOUNTPOINT,LABEL,PARTLABEL > <nodename>_lsblk.log
    8. 重要な情報を保存した後、サーバーを再起動します。
      # reboot
    9. ノードでイメージ変更が完了してオンラインに戻った後、ログインしてuname -rを実行し、OSがOracle Linux 7になっていることを確認します。
      次に、/root/BDA_IMAGING_*を確認します。このディレクトリが存在する場合、イメージ変更は成功しています。
    10. エラーが発生していない場合は、再びサーバーを再起動します。
      再起動が完了したら、/root/BDA_REBOOT_*が存在することを確認し、再起動が成功したことを確認します。(通常、これらのファイルは空です。)
    11. イメージ変更が完了してサーバーが再起動したら、/root/Extras/bdarestorenode.shのアクセス権を変更して、rootが実行できるようにします(chmod 700)。次にスクリプトを実行します。
      # /root/Extras/bdarestorenode.sh
      このスクリプトが正常に完了したことを確認します。
    12. このノードに必要なサーバー固有のカスタマイズまたはサード・パーティのソフトウェアのインストールを実行します。
    13. 次のノードにログオンします。重要性の低いすべてのノードでこの処理を繰り返し、次に重要なノードでこの処理を繰り返します。Mammothノードは最後まで残します。これはMammothが実行されるノードで、通常はNode0です
  7. Mammothノード(通常はNode0)にログオンします。
  8. ./bdarestorenode.shを実行します。このスクリプトにより、RPMの更新がクラスタのすべてのノードに伝播されます
  9. クラスタの健全性の最終チェックを実行します。
    # mammoth -c

関連項目:

付録のOracle Linux 6からOracle Linux 7への移行での出力例には、bdadumpnode.sh、bdareimagenode.shおよびbdarestorenode.shの例があります。

10.9 このリリースに付属のオプション・ソフトウェアの有効化

Oracle Big Data Applianceには、オプションの多数のソフトウェア・パッケージが含まれています。初期インストールでこれらのパッケージをインストールするよう選択しなかった場合は、後でそれらの決定の一部を元に戻すことができます。場合によっては、bdacliユーティリティを使用してオプションのソフトウェアをすばやく有効にできます。それ以外の場合は、さらに設定と構成のステップが必要です。必要な場合は、関連するサーバー名、ポート、ユーザー名およびパスワードを指定する準備をします。

この項では、再構成オプションの例をいくつか示します。

注意:

構文の詳細は、「bdacli」を参照してください。

10.9.1 Oracle Big Data Connectorsの有効化または無効化

Oracle Big Data Connectorsは、Oracle Big Data Applianceデプロイメント・バンドルに含まれています。Oracle Big Data Applianceのユーザーは、外部ソースからOracle Big Data Connectorsをダウンロードする必要はありません。ただし、新しいバージョンをこのリリースのOracle Big Data Applianceで使用することが承認されている場合は、新しいバージョンをダウンロードしてインストールできます。

Oracle Big Data Connectorsには、次のものが含まれています。

  • Oracle Loader for Hadoop

  • Oracle SQL Connector for Hadoop Distributed File System

  • Oracle XQuery for Hadoop

  • Oracle R Advanced Analytics for Hadoopの説明は次のとおりです。

  • Oracle Datasource for Apache Hadoop

Oracle Big Data Applianceソフトウェアをインストールする前に、Oracle Big Data Appliance構成生成ユーティリティを使用して、インストール時にOracle Big Data Connectorsを有効にするようにMammothに指示できます。インストール後の任意の時点で、bdacliユーティリティを使用してOracle Big Data Connectorsを有効または無効にできます。 

# bdacli [enable|disable] bdc

関連項目:

次の項では、Oracle Big Data Connectorsの有効化および無効化の詳細を説明します。

10.9.1.1 Oracle Big Data Connectorsの追加

Oracle Big Data Connectorsのサポートを追加するとき、Oracle Data Integratorエージェントをインストールするかどうかを選択できます。インストールする場合は、MySQL DatabaseのrootユーザーおよびOracle Data Integratorユーザー(BDA_ODI_REPO)のパスワードを指定する必要があります。Cloudera Managerの管理ユーザーのパスワードがcluster_name-config.jsonに保存されていない場合、それも把握しておく必要があります。

次の手順では、bdacliユーティリティを使用します。

Oracle Big Data Connectorsをクラスタに追加する場合:

  1. プライマリ・ラックの第1 NameNode (node01)にrootとしてログインします。

  2. Oracle Big Data Connectorsを有効にします。

    # bdacli enable bdc
INFO: Logging all actions in /opt/oracle/BDAMammoth/bdaconfig/tmp/bda1node03-20140805110007.log and traces in /opt/oracle/BDAMammoth/bdaconfig/tmp/bda1node03-20140805110007.trc
INFO: This is the install of the primary rack
INFO: Checking if password-less ssh is set up
     .
     .
     .
Do you wish to enable ODI? [y/n]: y
Enter password for the BDA_ODI_REPO mysql user
Enter password: odi_password
Enter password again: odi_password
Enter password for the mysql root user
Enter password: root_password
Enter password again: root_password
WARNING: The password for the Cloudera Manager admin user is missing from the parameters file and is required for the installation.
Enter password: admin_password
Enter password again: admin_password
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     2    0     2    0     0    181      0 --:--:-- --:--:-- --:--:--   250
INFO: Creating environment.pp file ...
INFO: Making sure all puppet agents can be accessed.
INFO: Pinging puppet agents
INFO: Adding BDC to the cluster. This will take some time ...
     .
     .
     .
SUCCESS: Successfully reconfigured service
10.9.1.2 Oracle Big Data Connectorsの削除

Oracle Big Data Connectorsのサポートを削除する場合、次のユーザーのパスワードがcluster_name-config.jsonに保存されていないときは、それらのパスワードを指定する必要があります。

  • Cloudera Managerのadminユーザー

  • MySQL Databaseのrootユーザー(Oracle Data Integratorエージェントが有効になっている場合)

  • MySQL DatabaseのBDA_ODI_REPOユーザー(Oracle Data Integratorエージェントが有効になっている場合)

次の手順では、bdacliユーティリティを使用します。

Oracle Big Data Connectorsをクラスタから削除する場合:

  1. プライマリ・ラックの第1 NameNode (node01)にrootとしてログインします。

  2. Oracle Big Data Connectorsを削除します。

    # bdacli disable bdc
INFO: Logging all actions in /opt/oracle/BDAMammoth/bdaconfig/tmp/bda1node03-20140805104603.log and traces in /opt/oracle/BDAMammoth/bdaconfig/tmp/bda1node03-20140805104603.trc
INFO: This is the install of the primary rack
INFO: Checking if password-less ssh is set up
INFO: Executing checkRoot.sh on nodes 
 
/opt/oracle/BDAMammoth/bdaconfig/tmp/all_nodes #Step -1#
SUCCESS: Executed checkRoot.sh on nodes 
 
/opt/oracle/BDAMammoth/bdaconfig/tmp/all_nodes #Step -1#
INFO: Executing checkSSHAllNodes.sh on nodes 
 
/opt/oracle/BDAMammoth/bdaconfig/tmp/all_nodes #Step -1#
SUCCESS: Executed checkSSHAllNodes.sh on nodes 
 
/opt/oracle/BDAMammoth/bdaconfig/tmp/all_nodes #Step -1#
INFO: Reading component versions from 
 
/opt/oracle/BDAMammoth/bdaconfig/COMPONENTS
INFO: Creating nodelist files...
WARNING: The password for the Cloudera Manager admin user is missing from the parameters file and is required for the installation.
Enter password: admin_password
Enter password again: admin_password
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     2    0     2    0     0    184      0 --:--:-- --:--:-- --:--:--   250
WARNING: The password for the MySQL root user is missing from the parameters file and is required for the installation.
Enter password: root_password
Enter password again: root_password
INFO: Executing verifyMySQLPasswd.sh on nodes 
/opt/oracle/BDAMammoth/bdaconfig/tmp/all_nodes #Step -1#
SUCCESS: Executed verifyMySQLPasswd.sh on nodes 
 
/opt/oracle/BDAMammoth/bdaconfig/tmp/all_nodes #Step -1#
WARNING: The password for the MySQL BDA_ODI_REPO user is missing from the  parameters file and is required for the installation.
Enter password: odi_password
Enter password again: odi_password
INFO: Executing verifyMySQLPasswd.sh on nodes 
/opt/oracle/BDAMammoth/bdaconfig/tmp/all_nodes #Step -1#
INFO: Creating environment.pp file ...
INFO: Making sure all puppet agents can be accessed.
INFO: Pinging puppet agents
INFO: Removing big data connectors. This will take some time ...
     .
     .
     .
SUCCESS: Successfully reconfigured service

10.9.2 Oracle Big Data Spatial and Graphの有効化または無効化

Oracle Big Data Spatial and Graphは、Oracle Big Data Applianceデプロイメント・バンドルに含まれています。Oracle Big Data Applianceのユーザーは、外部ソースからOracle Big Data Spatial and Graphをダウンロードする必要はありません。

このソフトウェアは、いつでも有効または無効にできます。オプションは次のとおりです。

  • Oracle Big Data Applianceソフトウェアをインストールする前に、Oracle Big Data Appliance構成生成ユーティリティを使用して、インストール時にOracle Big Data Spatial and Graphを有効にするようにMammothに指示できます。

  • インストール後の任意の時点で、bdacliユーティリティを使用してOracle Big Data Spatial and Graphを有効または無効にできます。 

# bdacli [enable|disable] osg

関連項目:

10.9.3 自動サービス・リクエストの有効化または無効化

次の手順では、自動サービス・リクエストに対するサポートの追加方法を示します。

自動サービス・リクエストをサポートするには、次の手順を実行します。

  1. My Oracle Supportアカウントを設定してASRマネージャをインストールします。これは、Oracle Big Data Applianceで自動サービス・リクエストをアクティブ化する前に行います。「自動サービス・リクエストの設定」を参照してください。

  2. 自動サービス・リクエスト監視を有効にしてアセットをアクティブ化します。

    # bdacli enable asr
INFO: Logging all actions in /opt/oracle/BDAMammoth/bdaconfig/tmp/bda1node01-20130205075303.log and traces in /opt/oracle/BDAMammoth/bdaconfig/tmp/bda1node01-20130205075303.trc
     .
     .
     .
Enter the value for ASR_HOST [Default: ]: asr-host.example.com
Enter the value for ASR_PORT [Default: 162]:
Enter the value for ASR_SERVER_USER: jdoe
 
Please Check the values you entered for the ASR parameters
 
ASR_HOST = asr-host.example.com
ASR_PORT = 162
ASR_SERVER_USER = jdoe
 
Are these values correct (y/n): y
Enter password for user jdoe on machine asr-host.example.com
Enter password: password
Enter password again: password
INFO: Creating environment.pp file ...
INFO: Making sure all puppet agents can be accessed.
INFO: Pinging puppet agents
INFO: Setting up ASR on all nodes. This will take some time ...
     .
     .
     .

  3. 「自動サービス・リクエストのインストールの確認」のステップを完了します。

10.9.4 Kerberos認証の有効化

Kerberos認証は、次の手順で構成します。

注意:

Active Directory Kerberosを有効にすることを選択した場合は、最初にMOS (My Oracle Support)ドキュメント2029378.1および2013585.1を読みます。これらのドキュメントでは、必要な準備ステップについて説明し、既知の問題に関する重要情報を提供しています。

Kerberos認証をサポートするには、次の手順を実行します。

  1. 「インストールの前提条件」にリストされているKerberosの前提条件が完全に満たされていることを確認します。

  2. プライマリ・ラックの第1 NameNode (node01)にログインします。

  3. Kerberosを構成します。

    # bdacli enable kerberos
INFO: Logging all actions in /opt/oracle/BDAMammoth/bdaconfig/tmp/bda1node01-20131104072502.log and traces in /opt/oracle/BDAMammoth/bdaconfig/tmp/bda1node01-20131104072502.trc
     .
     .
     .
INFO: Executing checkRoot.sh on nodes /opt/oracle/BDAMammoth/bdaconfig/tmp/all_nodes #Step -1#
SUCCESS: Executed checkRoot.sh on nodes /opt/oracle/BDAMammoth/bdaconfig/tmp/all_nodes #Step -1#
SUCCESS: Password-less root SSH is setup.
 
 Do you want to setup KDC on a BDA node (yes/no): yes
 
 Please enter the realm name: EXAMPLE.COM
 
 Enter password for Kerberos database: password
 Enter password again: password
INFO: Executing changekrb5_kdc.sh on nodes bda1node01 #Step -1#
SUCCESS: Executed changekrb5_kdc.sh on nodes bda1node01 #Step -1#
SUCCESS: Successfully set the Kerberos configuration on the KDC
INFO: Setting up Master KDC
INFO: Executing setupKDC.sh on nodes bda1node01 #Step -1#
     .
     .
     .

bdacliによってKerberos用に自動構成されるサービス

bdacli enable kerberosを使用すると、クラスタ全体、およびMammothインストーラで事前構成されているサービス(HDFS、YARN、Spark、Hive、Hue、OozieおよびZookeeper)について、Kerberosが構成されます。これらのサービスについては、これ以上のステップは必要ありません。

HBaseまたはFlumeなどの追加および構成したサービスの場合、Cloudera Managerの使用による各サービス用のKerberosの構成について、Clouderaのドキュメントを参照してください。

10.9.5 Oracle Big Data SQLのインストール

Oracle Big Data SQLでは、Apache Hive、HDFS、Oracle NoSQL Database、Apache HBase、その他のNoSQLデータベースなど、複数のビッグ・データ・ソースに格納された非リレーショナル・データに対する問合せをサポートしています。これにより、分散データに対して統一した問合せが可能になり、異なる製品のデータ・ストアのデータがすべてOracleデータベースに格納されているかのようにシームレスに表示および分析できるようになります。

Oracle Big Data SQLはOracle Big Data Applianceインストール・バンドルに含まれています。別途ダウンロードする必要はありません。

関連項目:

この項は、Oracle Big Data Applianceのユーザーに対するOracle Big Data SQLインストールの概要です。Oracle Big Data SQLのインストール、構成および使用の完全な情報は、これらのドキュメントを参照してください。

注意:

Oracle Big Data SQLをOracle Big Data Applianceにインストールするにはライセンスが必要です。インストールのOracle Database側の追加ライセンスは必要ありません。

ライセンス要件の詳細は、Oracle Big Data Applianceライセンス情報ユーザー・マニュアルを参照してください。

Oracle Databaseへのサポートされる接続

Oracle Big Data Applianceへのインストール時、次のOracle Databaseシステムを接続するようにOracle Big Data SQLを構成できます。

Oracle Big Data SQLは、単一ノードのOracle Databaseとマルチノードのデータベース(Oracle RACなど)の両方に接続できます。

次のサポートの詳細は、互換性マトリクスを参照してください。

  • Oracleエンジニアド・システム。

  • その他のシステム。

  • Linux OSのディストリビューションとバージョン。

  • Hadoopディストリビューション。

  • 必要とされるパッチを含むOracle Databaseのリリース。

ネットワーク要件

Oracle Big Data ApplianceおよびOracle Databaseシステムは、イーサネットまたはインフィニバンドによってともにネットワーク接続される必要があります。(Oracle SuperClusterへの接続はインフィニバンドのみです)。Oracle DatabaseとOracle Big Data Applianceの間のイーサネット接続には、10 Gb/sイーサネットをお薦めします。

インストールのフェーズ

インストールはどの場合も2つのフェーズで構成され、3番目が含まれる場合があります。

  1. Oracle Big Data Applianceでのインストール。

    Oracle Big Data Appliance構成生成ユーティリティによって、Oracle Big Data SQLをインストールに含めるようにMammothに指示するフォーム・フィールドが提供されます。

    Mammothのインストール後、任意のときにbdacliユーティリティを使用してOracle Big Data SQLを有効にすることもできます。

  2. Oracle Databaseシステムでのインストール。

    インストールのこの部分は手動で実行する必要があります。データベース側のインストール・バンドルは、Oracle Big Data Applianceインストールを実行すると生成されます。このバンドルをOracle Databaseシステムの各コンピュート・ノードにコピーし、解凍してインストールする必要があります。

  3. オプションのセキュリティ機能およびユーザー・アクセス機能(デフォルトのインストールに含まれない)の有効化

    Oracle Big Data Applianceインストールをカスタマイズして、Oracle Big Data Applianceのデフォルトのインストールでは構成できない機能(データベース所有者以外のユーザーがアプライアンスのHadoopクラスタのデータに対してOracle Big Data SQL問合せを実行できるマルチユーザー認可など)を含めることができできます。(デフォルトで有効化されているデータベース認証と同様に)この機能のアクティブ化を完了するには、インストール・プロセスの3番目のステップが必要です。

関連項目:

データベース側バンドルのインストールおよびオプション機能の有効化の方法の詳細は、Oracle Big Data SQLインストレーション・ガイドに説明されています。

既存のOracle Big Data SQLインストールへのインストール

ソフトウェアの前のバージョンをアンインストールする必要はありません。インストールによって、以前インストールされたバージョンが現在のリリース・レベルにアップグレードされます。

注意:

以前のOracle Big Data SQLがすでにOracle Big Data Applianceに存在する場合、構成生成ユーティリティのフォーム・フィールドでインストールにOracle Big Data SQLを選択したかどうかに関係なく、Mammothインストーラはこのインストールを現在のリリース・レベルにアップグレードします。

Oracle Big Data Applianceで、ソフトウェアは構成管理サーバー(Cloudera Configuration Managerが実行されているノード)の/opt/oracle/BDSJaguarにインストールされます。

Kerberos保護環境に対するチケット更新の自動設定

環境がKerberosで保護されている場合、インストールはoracleアカウント・プリンシパルのチケットを1日に4回更新するcronジョブを自動的に設定します。この頻度は、AD Kerberos要件を満たすためのものです。余分のkinitはMIT Kerberosに無害です。必要に応じて、Oracle Big Data ApplianceとOracle Databaseシステムの両方に対して自動化が設定されます。

10.9.5.1 Oracle Big Data Applianceでのインストール

Oracle Big Data SQLは、Mammothまたはbdacliユーティリティでインストールできます。以前のリリースは、Oracle Big Data Appliance側で自動的にアップグレードされます。

これが初回のインストールの場合(前のリリースがインストールされていない)

ソフトウェアをインストールするようにMammothに指示:

Oracle Big Data SQLをOracle Big Data Appliance構成生成ユーティリティで選択することによってMammothインストールに含めることができます。ソフトウェアをインストールする各クラスタに対して選択する必要があります。

次の図に示すように、構成生成ユーティリティの「Cluster Definition」ページでOracle Big Data SQLインストールを設定します。

図10-1 構成生成ユーティリティのOracle Big Data SQLフィールド

図に構成生成ユーティリティの3つのOracle Big Data SQLフォーム・フィールドを示します

  1. ライセンスの問いに対して「Yes」を選択すると、他のオプションに進めます。「Install Big Data SQL?」に対しても「Yes」を選択します

  2. Oracle Big Data Applianceがイーサネットまたはインフィニバンド接続によってOracle Databaseシステムに接続されるかどうかを指定します。どちらの方法もサポートされます。

構成ファイルを生成すると、Oracle Big Data SQLインストールを実行する指示が<cluster name>-config.jsonファイルに追加されます。

bdacliを使用したMammoth後インストールの実行:

Oracle Big Data SQLをMammothインストールに含めなかった場合、Mammothインストール後にbdacliユーティリティを使用していつでも有効にできます。 
# bdacli enable big_data_sql

Mammothおよびbdacliはどちらも、選択したクラスタのすべてのDataNodeにOracle Big Data SQLをインストールします。

注意:

Oracle Big Data SQLインストレーション・ガイドで説明されているデータベース認証機能を利用するには、GUID/キーのペアを生成してインストールする必要があります。このプロセスは、キーを生成するためにCloudera Configuration Managerがインストールされているノードで次のコマンドを実行することによって開始します。 
# ./jaguar --requestdb <database name> databasereq

この後、Oracle Big Data SQLのデータベース側のインストールを実行する前に、そのキーを含むファイルをOracle Databaseサーバーにコピーします。データベース認証の有効化プロセスを完了するには、他にいくつかのステップがあります。キー・ファイルを生成するために使用されるJaguarユーティリティと、キーの生成およびインストールのプロセスについては、Oracle Big Data SQLインストレーション・ガイドのHadoop側のOracle Big Data SQLのインストールまたはアップグレードを一読してください。

以前のリリースのOracle Big Data SQLがすでにインストールされている場合

この場合、構成生成ユーティリティでOracle Big Data SQLを選択する必要はありません。Mammothは、以前のOracle Big Data SQLのリリースを、現在インストールされているすべてのクラスタで現在のバージョンに自動的にアップグレードします。

注意:

インストールのOracle Database側のアップグレードは自動ではありません。このガイドの説明に従って、ソフトウェアのデータベース側をインストールしてください。
10.9.5.2 デフォルトのOracle Big Data SQLインストールのカスタマイズ

MammothまたはbdacliでOracle Big Data SQLをインストールし、(カスタマイズは行わずに)これらの両方のユーティリティが生成する基本的なデータベース側インストール・バンドルをインストールした場合、Oracle Big Data SQLユーザーズ・ガイドで説明されているすべての機能にアクセスできます。ただし、この初期インストールを再構成して次の変更を行うことができます。

  • マルチユーザー認可の追加。

    以前のリリースのOracle Big Data SQLでは、HadoopおよびHiveデータに対するすべての問合せはoracleユーザーとして実行され、ユーザーを変更するオプションはありません。すべての場合でoracleは引き続き基礎となるユーザーですが、Oracle Big Data SQLでは、Hadoop Secure Impersonationを使用して他の指定されたユーザーのかわりにoracleアカウントにタスクを実行するように指示できるようになりました。これによって、oracleユーザーのみではなく、現在問合せを実行しているユーザーに基づくHDFSデータ・アクセスが可能になりました。

  • Oracle Big Data SQLによって使用されるネットワークの切替え。

  • Oracle Big Data SQLをサポートする物理接続がある場合、Oracle Big Data SQLを再インストールしなくても、Oracle Big Data ApplianceおよびOracle Databaseサーバーをイーサネットからインフィニバンド(またはその逆)に切り替えることができます。

これらの変更を元に戻す場合は、後でインストールをもう一度再構成できます。

構成でデータベース認証はデフォルトで有効化されますが、この機能を使用する場合は、認証の基礎であるGUID/キーのペアを生成およびインストールするプロセスを実行する必要があります。

Jaguarユーティリティを使用したインストールの再構成

Oracle Big Data SQLでJaguarユーティリティを使用して、デフォルトのインストールを再構成します。Jaguarは、インストールの構成可能パラメータを設定するJSONファイルを読み取ります。デフォルトの構成ファイルはbds-config.jsonですが、任意の名前を使用できます。カスタム構成を開始するお薦めの方法は、Mammothによって作成されたデフォルトのbds-config.jsonのコピーを作成し、このファイルにカスタマイズを追加することです。

jaguar reconfigureを実行すると、構成ファイルに設定したパラメータが操作によって読み取られ、インストールのOracle Big Data Appliance側がそれに応じて変更され、また、加えた機能変更をサポートする新しいデータベース側のインストール・バンドルが生成されます。

注意:

Jaguarは、インストールおよびアンインストールを含む多くの様々な操作を提供します。ただし、Oracle Big Data ApplianceにバンドルされているバージョンのOracle Big Data SQLをインストールした場合は、Jaguarのインストールおよびアンインストール操作を実行しないでください。構成生成ユーティリティまたはbdacliを使用して、ソフトウェアを有効化または無効化してください。

関連項目:

重要:

カスタム構成ファイルを作成して使用する場合、ファイルのバックアップを作成して安全な場所に格納するようにしてください。ファイルは構成のレコードであり、構成を再作成するために必要になる場合があります。誤って削除したりユーザーによって変更されることを防ぐためだけではありません。特定のMammothおよびbdacliプロセスでは、構成管理サーバー(構成マネージャが実行されるノード)のOracle Big Data SQLインストール・ディレクトリ/opt/oracle/BDSJaguarが削除または上書きされます。

  • Mammoth拡張(# mammoth -e)またはMammothアップグレード(# mammoth -p)では、Oracle Big Data SQLインストール・ディレクトリが削除されます。

  • 再プロビジョニング(# bdacli admin-cluster reprovision <node name>)では、ディレクトリの削除を求められます。

  • # bdacli installの再実行では、カスタム構成がデフォルト構成で上書きされます。

10.9.5.3 Oracle DatabaseシステムでのOracle Big Data SQLのインストール

Oracle Big Data ApplianceにOracle Big Data SQLをインストールすると、このプロセスによってデータベース側のインストール・バンドルも生成されます。Oracle Big Data ApplianceのHadoopデータに対してOracle Big Data SQL問合せを実行する予定のデータベース・システムに、このバンドルをインストールします。

  1. Oracle Big Data Applianceでのインストールが完了した後、構成管理サーバー(Cloudera Configuration Managerが実行されているOracle Big Data Applianceノード)にrootとしてログオンします。

  2. /opt/oracle/BDSJaguar/db-bundlesに移動します。

    このディレクトリのインストール・バンドルは、次のようにクラスタ名および作成タイムスタンプを含むZIPファイルです。 

    bds-3.2.0-db-<cluster name>-<yymmdd.hhmi>.zip

  3. Oracle Databaseシステムにこのバンドルをインストールするには、Oracle Big Data SQLインストレーション・ガイドのOracle Big Data SQLのOracle Database側のインストールまたはアップグレードの手順に従います。

    ヒント:

    前の項で説明したように、データベース側のバンドルをインストールする前にインストールをカスタマイズするために、Jaguar reconfigure操作を使用するオプションがあります。
10.9.5.4 Oracle Big Data SQLサービスの管理

Oracle Big Data SQLをアプライアンスにインストールすると、そのbd_cellサービスがインストールされ、HadoopクラスタのすべてのDataNodeで開始されます。

Oracle Big Data Applianceのbdacliユーティリティは、各DataNodeおよびクラスタ全体でOracle Big Data SQLサービスを管理する操作を提供します。

単一のDataNodeでのサービスのインスタンスの場合:

bdacli {start | stop | restart | status} big_data_sql_server <node name>

クラスタ内のすべてのインスタンスの場合:

bdacli {start | stop | restart | status} big_data_sql_cluster

注意:

bdacliユーティリティは、クラスタ全体でサービスをインストールまたはアンインストールするための# bdacli {enable | disable} big_data_sqlも提供します。デフォルト以外の構成パラメータを追加してインストールをカスタマイズした場合、これらのコマンドによってカスタム構成がデフォルトの構成で上書きされることに注意してください。これらを使用する場合、Jaguar再構成操作を使用してカスタマイズをリストアできるように、最初にカスタム構成ファイルのコピーをアーカイブしてください。

関連項目:

このガイドのbdacliリファレンスに、Oracle Big Data SQLおよび他のサービスの管理に使用できるbdacli操作を説明しています。
10.9.5.5 Oracle Big Data SQLのアンインストール

Oracle Big Data SQLを完全にアンインストールするには、Oracle Big Data ApplianceとOracle Databaseシステムの両方からソフトウェアを削除します。

Oracle Databaseシステムからのアンインストール

Oracle Big Data SQLのデータベース側をインストール/アンインストールするには、bds-database-install.shスクリプト・ユーティリティを使用します。

Oracle Databaseサーバー(またはマルチノード・データベースの各ノード)で、--uninstallパラメータを指定してbds-database-install.shを実行します。 
$ /bds-database-install.sh --uninstall --crs=false

注意:

データベース・ノードでGridが実行されていない場合、またはデータベースでGrid (CRS/ASM)を使用しない場合は、オプションの--crsパラメータを含めてfalseに設定します。

また、以前のリリースの--uninstall-as-primaryおよび--uninstall-as-secondaryパラメータがこのリリースでは非推奨になったことに注意してください。アンインストール・プロセスでプライマリ・クラスタとセカンダリ・クラスタを区別する必要がなくなりました。

Oracle Big Data Applianceからのアンインストール

bdacliを使用して、Oracle Big Data ApplianceのOracle Big Data SQLを無効化(アンインストール)します。 

# bdacli disable big_data_sql
このコマンドによって、クラスタ全体のすべてのDataNodeからソフトウェアがアンインストールされます。

10.9.6 HBaseの設定と構成

HBaseは、Oracle Big Data Applianceのインストールに含まれていますが、使用する前にさらにステップが必要になります。

構成マネージャを使用してHBaseの設定を完了してください。手順については、My Oracle SupportでOracle Big Data Appliance V2.2以上でのCloudera ManagerによるHBaseの構成(ドキュメントID 1588891.1)を参照してください。

10.10 その他の承認済ソフトウェアのインストール

Oracle Big Data Applianceデプロイメント・バンドルに含まれているオプションのソフトウェアに加えて、アプライアンスへのインストールがテスト済および承認済のその他のアプリケーションがあります。

このリストに含まれていないかOracle Big Data Applianceでの使用が承認されていないソフトウェアをインストールする場合は、Oracle Big Data Applianceライセンス情報ユーザー・マニュアルで説明されているガイドラインに従ってください。また、サポート担当者を判断するには、ライセンスのマニュアルを確認してください。

10.10.1 Oracle Enterprise Manager Cloud Controlに対するサポートの追加

Oracle Big Data Applianceは、13.2 PG、13.2、13.1および12.cのバージョンのEnterprise Manager System Monitoringプラグインfor Oracle Big Data Applianceをサポートしています。Enterprise Manager System Monitoringプラグインfor Oracle Big Data Applianceは、同じネットワークのOracle Enterprise Manager Cloud Controlインストール環境にインストールできます。

Oracle Enterprise Manager Cloud Controlプラグインのインストール

  1. 予備パッチ(選択したプラグイン・バージョンに必要な場合)をインストールします。

    13.1または12.cプラグインによるHTTPSを介したシステム監視を有効にするには、次の表に示されているパッチを最初にインストールする必要があります。これらのパッチは、Oracle Automated Release Updates (ARU)のサイトからダウンロードできます。13.2および13.2PGプラグインの場合、追加のパッチは必要ありません。
    Enterprise Managerシステム・モニタリング・プラグイン Oracle Big Data Applianceのプラグインをサポートするためのパッチ前提条件
    13.2および13.2 PG Enterprise Manager System Monitoringプラグイン。

    Oracle Big Data Applianceの場合、具体的な13.2 PGバージョンはEnterprise Manager for Big Data Appliance (13.2.2.0.0)です。

    		パッチは必要ありません。
    13.1 Enterprise Managerシステム・モニタリング・プラグイン

    • OMSサイド・パッチ: 23294904

    • エージェント・プラグイン : 23294778

    • Discoveryプラグイン : 23294785
    12.c Enterprise Managerシステム・モニタリング・プラグイン    

    • OMSサイド・パッチ: 23218275

    • BDAプラグインDiscovery OHパッチ: 23218115および23218109.

  2. Enterprise Managerシステム・モニタリング・プラグインをインストールします。

    バージョン13.1のプラグインをインストールする手順は、Oracle Enterprise Manager System Monitoring Plug-inインストレーション・ガイドfor Oracle Big Data Applianceを参照してください。バージョン13.2および13.2 PGをインストールする場合も、これらと同じ手順を使用できます。

    12.cプラグインのインストール手順の詳細は、My Oracle Supportのドキュメント(Download/Deployment of the 12c EM May Bundle Patch to Support Discovery/Monitoring of Cloudera Manager Admin Console HTTPS URLS (Doc ID 2148611.1))を参照してください。

13.2 PG for Oracle Big Data Applianceの新機能

13.2 PGプラグインfor Oracle Big Data Applianceでは、次のターゲットのサポートが追加されました。

  • Kafka

  • Sentry

  • Sqoop2

  • キー管理サービス

  • キー・トラスティ・サービス

  • クラスタ・セキュリティ

関連項目:

Oracle Big Data Applianceリリースの相互参照および互換性のあるOracle Enterprise Managerプラグインについては、My Oracle Supportの次のノートを参照してください。

『Oracle Enterprise Manager Cloud Control Big Data Applianceプラグイン互換性マトリクス(BDA V4.5以上)』(Doc ID 2267589.1)

10.10.2 Oracle Big Data Discoveryのインストール

Oracle Big Data Discoveryは、Big Dataのビジュアル分析用のエンドツーエンド製品です。

Oracle Big Data Discovery 1.6は、この製品のライセンスがある場合に、Oracle Big Data Appliance上にインストールできます。以前のリリースのOracle Big Data Discoveryはサポートされていません。

このソフトウェアは、Oracle Software Delivery Cloud (https://edelivery.oracle.com)からダウンロードできます。

Big Data DiscoveryをOracle Big Data Applianceと使用するための方法は2つあります。BDAの5番目のノードでのbdacliの使用、およびMammoth管理対象外のエッジ・ノードでのbdacliの使用です。

  • Oracle Big Data Applianceクラスタ内のノード5にソフトウェアをインストールします。

    このインストールでは、WebLogic Server、Studio、DgraphおよびすべてのOracle Big Data Discoveryコンポーネントがノード5にインストールされます(クラスタ内の他のノードには配布されない)。これは、このガイドで説明されている方法です。これは、Oracle Data Applianceクラスタ内でソフトウェアをインストールするためにサポートされている唯一の方法です。Oracle Big Data Discoveryインストレーション・ガイドで説明されているインストール方法を使用してOracle Big Data Applianceクラスタ内でOracle Big Data Discoveryをインストールしないでください。

  • Oracle Big Data Applianceで管理されていないエッジ・ノードにソフトウェアをインストールします。

    エッジ・ノードにBig Data Discoveryをインストールしている場合、Oracle Big Data Discovery用のOracle Big Data Applianceのインストール手順は適用されません。エッジ・ノードの場合は、Oracle Big Data Discoveryインストレーション・ガイドで説明されている通常のインストール手順に従う必要があります。

10.10.2.1 Oracle Big Data DiscoveryがOracle Big Data Applianceにデプロイされる方法

すべてのOracle Big Data Discovery (BDD)コンポーネントは単一ノードにインストールされます。Oracle Big Data Discoveryは、クラスタの5番目のノードにインストールされます(ここでは「ノード5」と呼びます)。BDDを有効化すると、クラスタは残りのノードを構成します。たとえば、スタータ・ラックのノード1、2、3、4、6です。 必要に応じて、Oracle Big Data Discoveryを無効化してノード5をCDHクラスタに戻すこともできます。Hadoopクラスタの1ノードを専用にする余裕がない場合は、Oracle Big Data Appliance外部のサーバーにこのソフトウェアをインストールして、データ処理のためにOracle Big Data Applianceクラスタを使用できます。その場合、この項の手順は使用しないでください。かわりに、その他のインストール・オプションは、Oracle Help CenterにあるOracle Big Data Discovery製品のドキュメントを参照してください。

制限:

このインストールはOracle Linux 5を実行するOracle Big Data Applianceシステムではサポートされません。

ノード5をBig Data Discoveryで再利用するために、サーバーのドライブ・アレイに現在存在するデータがインストールによってすべて削除されます。最初に、必要なディスク容量がクラスタ内の他の場所に存在することを確認します。この要件が満たされる場合、サーバー上のすべてのHadoopブロックを他のノードに再配分します。Hadoopデータは何も失われません。インストールでは、サーバー上のDataNodeおよびNodeManagerがプロビジョニング解除され、データ・パーティション(/u03から/u12)が消去されます。/boot、root (/)および最初の2つのデータ・パーティション(/u01および/u02)のみがそのまま残されます。

重要:

Oracle Big Data Discoveryをインストールする前に保存する必要のある非Hadoopデータをバックアップまたは移動するのはお客様の責任です。インストールでは、ノード5に格納されているいかなる非Hadoopデータも移動されません。ノード5のデータ・パーティション/u03-/u12に存在する非Hadoopデータは、インストールがこれらのデータ・パーティションを消去したときに失われます。
10.10.2.2 Oracle Big Data Discoveryのインストールおよび有効化

このリリースのOracle Big Data Applianceでは、Oracle Big Data Discovery 1.6のみがサポートされています。

バージョン1.6のOracle Big Data Discoveryは、Oracle Software Delivery Cloudからダウンロードできます。

Oracle Big Data DiscoveryをOracle Big Data Applianceにインストールするには、My Oracle Supportのサポート・ドキュメント2150755.1 – How to Enable/Disable Oracle Big Data Discovery 1.2.2 on Oracle Big Data Appliance V4.5/CDH5.7.1/OL6 with bdacliで説明されている手順に従ってください。これらの手順は、Oracle Big Data Appliance 4.5にOracle Big Data Discoveryの以前のリリースをインストールするためのものですが、現在のOracle Big Data ApplianceリリースでのOracle Big Data Discovery 1.6のインストールにも使用できます。ただし、これらのステップを次のように変更する必要があります。

  • CDHをアップグレードする手順は無視してください。このリリースのOracle Big Data Applianceでは廃止されています。

  • パッケージ・ダウンロードの前提条件の項で、バージョン1.6を選択します。

  • BDDの有効化の項のステップ2では、バージョン1.2.2のダウンロード・パッケージをコピーしてファイル名を変更する方法について説明しています。これは無視してください。Oracle Software Delivery Cloudのパッケージ・ダウンロードに、ファイルのリストが表示されます。ファイル名とそれぞれの説明を書き留めてください。ダウンロード後に次のようにファイル名を変更します。

    ファイルの説明 ファイル名を変更してコピーする先...

    Oracle Big Data Discoveryバイナリの2つの部分の1番目

    		 /opt/oracle/bdd/bdd1.zip

    Oracle Big Data Discoveryバイナリの2つの部分の2番目

    		 /opt/oracle/bdd/bdd2.zip

    Oracle Big Data Discoveryのインストーラ

    		 /opt/oracle/bdd/installer.zip

    Oracle Fusion Middleware WebLogic ServerおよびCoherence

    		 /opt/oracle/bdd/ (名前変更なし)

    前述のJARファイルをWebLogic ServerおよびCoherence zipファイルから解凍します。

My Oracle Supportのノートに記載されている残りの手順に従います。

重要: Oracle Big Data Discoveryのアップグレード:

既存のOracle Big Data Discoveryのインストール環境をアップグレードするために、ここまたはMy Oracle Supportのドキュメント(2150755.1)で説明しているインストール手順を使用しないでください。Oracle Big Data Discoveryアップグレード・ガイドのアップグレード手順に従います。
10.10.2.3 Oracle Big Data Discoveryの使用方法

ソフトウェアの使用手順は、Oracle Help CenterのOracle Big Data Discoveryに関するドキュメントを参照してください。このサイトには、Oracle Big Data Discoveryの削除、再インストール、アップグレードまたは再構成の手順が含まれています。これらは、Oracle Big Data Applianceにこのソフトウェアをインストールした状態で使用すべきでないことに注意してください。 これについて疑問がある場合はOracleサポートに問い合せてください。

10.10.3 Cloudera Data Science Workbenchのインストール

Cloudera Data Science Workbench (CDSW)は、Oracle Big Data Applianceにインストールできます。

Oracle Linux 7を実行するOracle Big Data Applianceエッジ・ノードにCloudera Data Science Workbenchをインストールできます。Mammoth管理対象または管理対象外のエッジ・ノードを使用できます。

インストール手順は、ClouderaのドキュメントのWebサイト(https://www.cloudera.com/documentation.html)で入手できます。

注意:

Cloudera Data Science Workbenchは、Oracle Big Data Applianceのライセンスに含まれておらず、Oracle Big Data Applianceではサポートされていません。ライセンスおよびサポート情報については、ClouderaのWebサイトを参照してください。

この製品は、Oracle Big Data Applianceデプロイメント・バンドルに含まれていません。インストール・パッケージをClouderaのWebサイトからダウンロードできます。

関連項目:

10.11 ベース・イメージの再インストール

Oracle Big Data Applianceには、「Oracle Big Data Appliance管理ソフトウェア」の説明どおり、オペレーティング・システムおよび様々なユーティリティが工場出荷時にインストールされています。たとえば、Oracle Big Data Applianceを元の状態に戻す場合、または障害サーバーを交換した場合、このベース・イメージの再インストールが必要になる場合があります。Mammothでは、Oracle Big Data Applianceソフトウェアを新しいバージョンにアップグレードする前に、必要に応じてベース・イメージが自動的にアップグレードされます。

ラックのすべてまたは一部のイメージを変更できます。ただし、クラスタ内のすべてのサーバーは同じイメージである必要があります。適切な手順を実行します。

注意:

ベース・イメージ・バージョンが4.5.0-6より前の場合、イメージ変更の前に、ベース・イメージをBDA v4.5.0-6に更新するためにパッチ23241894を適用することをお薦めします。パッチの詳細は、My Oracle Supportのドキュメント2135358.1を参照してください。

10.11.1 単一のOracle Big Data Applianceサーバーのイメージの変更

この手順を実行して単一のサーバーのイメージを変更します。たとえば、次のように障害サーバーを交換する場合を見てみます。

注意:

サーバーのイメージを変更すると、すべてのファイルとデータが消去されます。

単一のサーバーにベース・イメージを再インストールするには、次の手順を実行します。

  1. My Oracle SupportまたはOracle Automated Release Updates (ARU)からベース・イメージ・パッチをダウンロードして、イメージを変更するサーバーにコピーします。

    注意:

    ベース・イメージの最新のバージョン4.xを使用します。Mammothバンドルに含まれているバージョンは使用しないでください。

    「Mammothソフトウェア・デプロイメント・バンドルのダウンロード」を参照してください。My Oracle Supportから基本イメージ・パッチをダウンロードするのと同じ基本ステップを使用できます。

  2. 現在のカスタマ設定のイメージをサーバーに再適用するには、意図したネットワーク構成が/opt/oracle/bda/rack-network.jsonおよび/opt/oracle/bda/cluster-network.jsonに反映されていることを確認します。反映されていない場合は、Oracle Big Data Appliance構成生成ユーティリティを使用して新しいファイルのセットを生成します。「構成ファイルの生成」を参照してください。

    (/opt/oracle/bda/network.jsonの使用はまだサポートされていますが、推奨していません。)

  3. パーティションに4GB以上の空きディスク領域があることを確認します。

    $ df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/md2              161G   23G  130G  15% /
/dev/md0              194M   40M  145M  22% /boot
tmpfs                  24G     0   24G   0% /dev/shm
/dev/sda4             1.7T  197M  1.7T   1% /u01
/dev/sdb4             1.7T  197M  1.7T   1% /u02
/dev/sdc1             1.8T  199M  1.8T   1% /u03
/dev/sdd1             1.8T  199M  1.8T   1% /u04
     .
     .
     .

  4. ダウンロードしたベース・イメージのZIPファイルを解凍します。次の例は、コマンドラインへの出力の一部を示しています。

    # unzip p<number>_<version>_Linux-x86-64.zip
Archive: p<number>_Linux-x86-64.zip
creating: BDABaseImage-ol7-<version>_RELEASE/
creating: BDABaseImage-ol7-<version>_RELEASE/Extras/
creating: BDABaseImage-ol7-<version>_RELEASE/Extras/BALANCER/
extracting: BDABaseImage-ol7-<version>_RELEASE/Extras/BALANCER/orabalancer-<version>-h2.zip
inflating: BDABaseImage-ol7-<version>_RELEASE/Extras/BALANCER/orabalancer-<version>-h2.noarch.rpm
extracting: BDABaseImage-ol7-<version>_RELEASE/Extras/BALANCER/orabalancerdemo-<version>-h2.zip
creating: BDABaseImage-ol7-<version>_RELEASE/Extras/CELL/
inflating: BDABaseImage-ol7-<version>_RELEASE/Extras/CELL/bd_cell-<version>_LINUX.X64_160506.11
...

  5. 前のステップで作成したサブディレクトリに移動します。

    # cd BDABaseImage-ol7-<version>_RELEASE

  6. イメージを変更するサーバーにログインし、makebdaimageコマンドを実行します。次の例は、ベース・イメージから構成ファイルのカスタム設定にノード4のイメージを変更するコマンド(内部USBを含む)を示しています。 rack-network.jsonおよびcluster-network.jsonをカンマで区切り、1つのパラメータとして送信します。 

    # ./makebdaimage -usbint BDABaseImage-<version>_RELEASE.iso /opt/oracle/bda/rack-network.json,/opt/oracle/bda/cluster-network.json 4

    network.jsonファイル・パラメータとして送信することはできますが、推奨していません。 

    # ./makebdaimage -usbint BDABaseImage-<version>_RELEASE.iso /opt/oracle/bda/network.json 4

  7. makebdaimageコマンドがエラーなしに成功した場合には、サーバーを再起動します。

10.11.2 Oracle Big Data Applianceラックのイメージの変更

この手順を実行して、ラック全体のイメージを変更します。

注意:

ラック全体のイメージを変更すると、ラック上のすべてのクラスタ、ファイルおよびデータが消去されます。イメージの変更は、ソフトウェアのアップグレードには必要ありません。

ラックのすべてのサーバーにベース・イメージを再インストールするには、次の手順を実行します。

  1. Oracle Big Data Applianceソフトウェアを以前にラックにインストールしている場合、Oracle Big Data Appliance以外の安全な場所に/opt/oracle/BDAMammoth/cluster_name-config.jsonファイルを保存します。

  2. My Oracle SupportまたはOracle Automated Release Updates (ARU)から最新のベース・イメージ・パッチをダウンロードして、イメージを変更するラックの第1サーバー(最下部)にコピーします。

    「Mammothソフトウェア・デプロイメント・バンドルのダウンロード」を参照してください。My Oracle Supportから基本イメージ・パッチをダウンロードするのと同じ基本ステップを使用できます。

    注意:

    ベース・イメージの最新のバージョン4.xを使用します。Mammothバンドルに含まれているバージョンは使用しないでください。

  3. 第1サーバーのSSH接続を確立して、rootとしてログインします。

  4. 既存のカスタマ・ネットワーク設定のイメージを再適用するには、意図したネットワーク構成が/opt/oracle/bda/network.jsonに反映されていることを確認します。反映されていない場合は、Oracle Big Data Appliance構成生成ユーティリティを使用して新しいファイルを生成します。

  5. パスワードなしSSHが設定されていることを確認します。

    # dcli hostname
192.168.41.37: bda1node01.example.com
192.168.41.38: bda1node02.example.com
192.168.41.39: bda1node03.example.com
     .
     .
     .

    このコマンドがエラーなしで実行されると、Oracle Big Data Applianceのすべてのサーバーのホスト名が返されます。そうではない場合、「パスワードなしSSHの設定」のステップに従ってください。すべてのサーバーでdcli hostnameコマンドが正常に実行されるまで、作業を継続しないでください。

  6. すべてのOracle Big Data Applianceサーバーでハードウェアの問題をチェックします。

    # dcli bdacheckhw | grep -v SUCCESS

  7. ラックにイメージを再適用する前に、ハードウェアのエラーおよび警告を解決します。

  8. すべてのサーバーのルート(/)パーティションが4GB以上空いていることを確認します。

  9. # dcli df -h /
192.168.41.37: Filesystem            Size  Used Avail Use% Mounted on
192.168.41.37: /dev/md2              161G   21G  132G  14% /
192.168.41.38: Filesystem            Size  Used Avail Use% Mounted on
192.168.41.38: /dev/md2              161G   19G  135G  12% /
192.168.41.39: Filesystem            Size  Used Avail Use% Mounted on
192.168.41.39: /dev/md2              161G   23G  131G  15% /
     .
     .
     .

  10. ダウンロードしたベース・イメージのZIPファイルを解凍します。次に例を示します。

    # unzip p<number>_<version>_Linux-x86-64.zip
Archive:  p<number>_<version>_Linux-x86-64.zip    
creating: BDABaseImage-ol6-<version>_RELEASE/   
inflating: BDABaseImage-ol6-<version>_RELEASE/biosconfig     
inflating: BDABaseImage-ol6-<version>_RELEASE/makebdaimage    
extracting: BDABaseImage-ol6-<version>_RELEASE/BDABaseImage-ol6-<version>_RELEASE.md5sum     
inflating: BDABaseImage-ol6-<version>_RELEASE/reimagerack     
inflating: BDABaseImage-ol6-<version>_RELEASE/reimagecluster     
inflating: BDABaseImage-ol6-<version>_RELEASE/BDABaseImage-ol6-<version>_RELEASE.iso      
.
.
.

  11. 前のステップで作成したサブディレクトリに移動します。

    # cd BDABaseImage-ol6-<version>_RELEASE

  12. 次のいずれかの手順を完了します。

    • カスタマ・ネットワーク用に構成されたOracle Big Data Applianceにイメージを再適用して同じカスタマ・ネットワーク設定にするには、./reimagerackコマンドを実行します。

    • 工場出荷時の設定を維持するアプライアンスのイメージに変更するには、次のようにします。

      1. /opt/oracle/bda/network.jsonが存在しないことを確認します。

      2. ./reimagerackコマンドを実行します。

    • カスタム・ネットワーク設定を使用して構成されたラックで工場出荷時のネットワーク設定をリストアするには、次のようにします。

      1. Oracle Big Data Appliance以外の安全な場所に/opt/oracle/bda/network.jsonをコピーします。

      2. /opt/oracle/bda/BdaShip.jsonが存在することを確認します。

      3. ラックのイメージを変更します。

        ./reimagerack deploy ship

  13. Mammothを実行します。

関連項目:

10.11.3 Oracle Big Data Applianceクラスタのイメージの変更

この手順を実行して、Mammothユーティリティが単一クラスタとしてデプロイしたサーバー・グループのイメージを変更します。Mammothが単一クラスタとしてデプロイしたサーバー・グループでのみ使用できます。現在のネットワーク設定を再適用することも、工場出荷時の設定に戻すこともできます。

注意:

クラスタのイメージを変更すると、クラスタ上のすべてのファイルとデータが消去されます。イメージの変更は、ソフトウェアのアップグレードには必要ありません。

必須の前提条件

Oracle Big Data Appliance構成ユーティリティで生成されたファイル<rack_name>-rack-network.jsonおよび<cluster_name>-cluster-network.jsonの名前をrack-network.jsonおよびcluster-network.jsonにそれぞれ変更する必要があります。つまり、ラック名とクラスタ名の接頭辞と最初のハイフンを取ります。これらの接頭辞の唯一の目的は、構成ユーティリティの出力でクラスタまたはラックを区別することです。

重要:

イメージを変更する前に、 /opt/oracle/bda/rack-network.jsonおよび/opt/oracle/bda/rack-network.jsonがクラスタのすべてのノードに存在している必要があります。

クラスタ内のすべてのサーバーのベース・イメージを再インストールするには、次の手順を実行します。

ヒント:

reimageclusterユーティリティは、ラックの各サーバーの内部USBドライブにインストーラを作成し、インストールを初期化して各サーバーを再起動します。サーバーが再起動のために停止している間、Integrated Lights Out Manager (ILOM)を使用して各サーバーにログオンし、進捗を監視できます。 
<server name>-ilom.<domain>.com

「Remote Control」、「Redirection」、「Launch Remote Console」の順にクリックし、イメージの変更をモニタリングするJavaコンソールを起動します。

  1. Oracle Big Data Applianceソフトウェアを以前にラックにインストールしている場合、Oracle Big Data Appliance以外の安全な場所に/opt/oracle/BDAMammoth/mammoth-<rack_name>.paramsファイル(または/opt/oracle/BDAMammoth/<cluster_name>-config.json)を保存します。クラスタがアップグレードされている場合、ファイルは/opt/oracle/BDAMammoth/previous-BDAMammothディレクトリに存在している可能性があります。

  2. Oracle Big Data Applianceベース・イメージのTARファイルをMy Oracle Supportから一時ディレクトリにダウンロードします。イメージを変更するクラスタの最初の(最も下にある)サーバーにコピーします。

  3. イメージ変更を現在の設定に適用する場合は、意図したネットワーク構成が/opt/oracle/bda/rack-network.jsonおよびcluster-network.jsonに反映されていることを確認します。そうでない場合は、Oracle Big Data Appliance構成生成ユーティリティを使用して新しいファイルを生成します。

  4. 第1サーバーのSSH接続を確立して、rootとしてログインします。

  5. パスワードなしSSHがクラスタに設定されていることを確認します(dcli -C hostnameがエラーなしで動作する必要があります)。設定されていない場合は、setup-root-ssh -Cを実行します。 

    # setup-root-ssh -C 
Enter root password: 
... 
... 
setup-root-ssh succeeded

    dcli -C hostnameがエラーなしで実行されると、クラスタ内のすべてのOracle Big Data Applianceサーバーのホスト名が返されます。そうではない場合、「パスワードなしSSHの設定」のステップに従ってください。すべてのサーバーでdcli -C hostnameコマンドが正常に実行されるまで、作業を継続しないでください。

  6. すべてのサーバーのルート(/)パーティションが4GB以上空いていることを確認します。

    # dcli -C df -h /
10.xxx.xxx.xx: Filesystem      Size  Used Avail Use% Mounted on 
10.xxx.xxx.xx: /dev/md2        459G   49G  387G  12% / 
10.xxx.xxx.xx: Filesystem      Size  Used Avail Use% Mounted on
...

  7. ダウンロードしたベース・イメージのZIPファイルを解凍します。次に例を示します。

    # unzip p<number>_<version>_Linux-x86-64.zip
Archive: p<number>_<version>_Linux-x86-64.zip
creating: BDABaseImage-ol7-<version>_RELEASE/
creating: BDABaseImage-ol7-<version>_RELEASE/Extras/
creating: BDABaseImage-ol7-<version>_RELEASE/Extras/BALANCER/
extracting: BDABaseImage-ol7-<version>_RELEASE/Extras/BALANCER/orabalancer-<version>-h2.zip
inflating: BDABaseImage-ol7-<version>_RELEASE/Extras/BALANCER/orabalancer-<version>-h2.noarch.rpm
extracting: BDABaseImage-ol7-<version>_RELEASE/Extras/BALANCER/orabalancerdemo-<version>-h2.zip
creating: BDABaseImage-ol7-<version>_RELEASE/Extras/CELL/
inflating: BDABaseImage-ol7-<version>_RELEASE/Extras/CELL/bd_cell-<version>_LINUX.X64_160506.11   
...

  8. 前のステップで作成したサブディレクトリに移動します。

    # cd BDABaseImage-ol7-<version>_RELEASE

  9. 次の手順のいずれかに従って、Oracle Big Data Appliance全体のイメージを変更します。第1の方法は、既存の設定を維持することです。第2の方法は、工場出荷時の設定(Oracle Big Data Appliance Configuration Utility設定の前)に戻すことです。

    既存のネットワーク設定のイメージの変更および維持

    1. /opt/oracle/bda/に、network.jsonおよびBdaShip.jsonの両方がリストされていることを確認します。 

      # ls *.json
network.json BdaShip.json

      network.jsonがリストされていない場合、customer-specific network.jsonファイル(維持する構成を記述したファイル)を探します。まず、このファイルがネットワーク設定を正しく定義していることを確認します。定義していない場合は、Oracle Big Data Appliance構成生成ユーティリティを使用して新しいファイルを生成します。ファイルを/opt/oracle/bdaにコピーし、ファイル名をnetwork.jsonに変更します。

    2. dcliコマンドを使用して、network.jsonをクラスタのすべてのノードにコピーします。 

      #  dcli -C -f /opt/oracle/bda/network.json -d /opt/oracle/bda/

    3. ./reimageclusterコマンドを実行します。 このコマンドにより表示される出力の一部を次に示します。 

      # ./reimagerack
Passwordless SSH set up to all hosts : xxx.xxx.xx.xx xxx.xxx.xx.xx xxx.xxx.xx.xx xxx.xxx.xx.xx xxx.xxx.xx.xx 
 xxx.xxx.xx.xx 
Using /tmp/BDABaseImage-ol7-<version>_RELEASE/BDABaseImage-ol7-<version>_RELEASE.iso to re-image
BDABaseImage-ol7-<version>_RELEASE.iso: OK
Re-imaging to existing customer network settings

FINAL CONFIRMATION : All of the following hosts will be completely erased, re-imaged and initialized including resetting of the iloms: xxx.xxx.xx.xx xxx.xxx.xx.xx xxx.xxx.xx.xx xxx.xxx.xx.xx xxx.xxx.xx.xx xxx.xxx.xx.xx
Proceed [y/n]?
y
Running hardware checks on all nodes...
...
Rebooting all servers  
Broadcast message from root@bda1node01.example.com (unknown) at 15:58 ...  
The system is going down for reboot NOW!

    工場出荷時のネットワーク設定のイメージの復元

    1. ステップ1で説明したように、/opt/oracle/bda/rack-network.jsonおよびcluster-network.jsonがOracle Big Data Applianceの外部の安全な場所にコピーされており、/opt/oracle/bda/BdaShip.jsonが存在することを確認します。

    2. 次のコマンドを使用して、クラスタのイメージを工場出荷時の設定に戻します。

      # ./reimagecluster deploy ship
  10. 既存のネットワーク設定を変更する場合も、工場出荷時の設定に戻す場合も、最後のステップは同じです。reimageclusterによる再起動が完了した後、setup-root-sshを実行し、ラックのすべてのサーバーとの接続を確立します。 dcliコマンドを使用してすべてのサーバーをもう一度再起動できるようにするには、この作業が必要です。
    # setup-root-ssh
Enter root password:
...
setup-root-ssh succeeded

  11. dcli再起動コマンドを使用して、すべてのサーバーをもう一度再起動します。

    # dcli reboot

  12. ファイル/root/BDA_IMAGING_SUCCEEDEDおよび/root/BDA_REBOOT_SUCCEEDEDが、ラックの各サーバーに存在することを確認します。 

    # dcli ls -lrt /root/BDA_*

    /root/BDA_REBOOT_SUCCEEDEDの日付およびタイムスタンプが、イメージ変更プロセスにおける再起動の時間に一致していることを確認します。ファイルは0バイトである場合も、INFOメッセージが含まれる場合もあります。

  13. インストールされたベース・イメージのバージョンを確認します。

    # imageinfo
Big Data Appliance Image Info
IMAGE_VERSION : <version>
IMAGE_CREATION_DATE : Tue Mar 19 20:19:54 UTC 2019
IMAGE_LABEL : BDA_<version>_LINUX.X64_RELEASE
LINUX_VERSION : Oracle Linux Server release <version>
KERNEL_VERSION : 2.<version>.el6uek.x86_64
BDA_RPM_VERSION : bda-<version>-1.el6.x86_64
OFED_VERSION : OFED-IOV-<version>
JDK_VERSION : jdk1.<version>-fcs.x86_64

Mammothユーティリティを起動し、システムをOracle Big Data Applianceの最新のバージョンにすることができるようになります。

関連項目:

10.12 個別パッチのインストール

個別パッチ・バンドルは、1つ以上のリリースの特定の不具合に対する修正を提供します。Mammothを使用してクラスタにパッチを適用します。

個別パッチ・バンドルをインストールするには、次の手順を実行します。

  1. 自動リリース更新(ARU)システムからパッチ・バンドルをOracle Big Data Applianceクラスタの第1ノードのディレクトリ(/tmpなど)にダウンロードします。

    ファイルは、BDA-patch-release-patch.zipという名前です。この手順の例では、BDA-patch-<version>-123456.zipの名前を使用します。

  2. ファイルを解凍します。次に例を示します。

    # unzip BDA-patch-<version>-123456.zip
Archive:  BDA-patch-<version>-123456.zip
   creating: BDA-patch-<version>-123456/
  inflating: BDA-patch-<version>-123456/BDA-patch-<version>-123456.run 
  inflating: BDA-patch-<version>-123456/README.txt

  3. ステップ2で作成したパッチ・ディレクトリに移動します。次に例を示します。

    $ cd BDA-patch-<version>-123456

  4. 実行ファイルの内容を抽出します。次に例を示します。

    $ ./BDA-patch-<version>-123456.run
Big Data Appliance one-off patch 123456 for v<version> Self-extraction
 
Removing existing temporary files
 
Generating /tmp/BDA-patch-<version>-123456.tar
Verifying MD5 sum of /tmp/BDA-patch-<version>-123456.tar
/tmp/BDA-patch-<version>-123456.tar MD5 checksum matches
 
Extracting /tmp/BDA-patch-<version>-123456.tar to /opt/oracle/BDAMammoth/patches/123456
Removing temporary files
 
Please "cd /opt/oracle/BDAMammoth" before running "./mammoth -p 123456"

  5. BDAMammothディレクトリに移動します。

    $ cd /opt/oracle/BDAMammoth

  6. パッチをインストールします。次に例を示します。

    $ ./mammoth -p 123456

    Mammothにより、パッチをローリング・アップグレードとしてロードするかどうかを選択するプロンプトが表示されます。(「ローリング・アップグレードについて」を参照してください)

    あるいは、bdacliコマンドを使用できます。「bdacli」を参照してください。

10.13 Mammothソフトウェア・インストールおよび構成ユーティリティ

Mammothを使用するには、rootとして第1サーバーにログインし、/opt/oracle/BDAMammothディレクトリに移動する必要があります。構文は次のとおりです。 

./mammoth option [cluster_name] ]

このコマンドで、cluster_nameはクラスタの名前です。cluster_nameは、cluster_name-config.jsonに示されているとおり、最初のコマンドに正確に入力する必要があります。その後、cluster_nameはデフォルトで前のmammothコマンドで指定されたラックになります。

あるラックのインストールを完了してから、別のラックのインストールを開始する必要があります。

例10-1 Mammothの構文例

次のコマンドでは、Mammothユーティリティのヘルプを表示します。

./mammoth -h

次のコマンドでは、ラックbda3に対して完全なインストールを実行します。

./mammoth -i bda3

次のコマンドでは、一連のインストール・ステップを示します。

./mammoth -l

このコマンドでは、設定中のラックに対してステップ2から6を実行します。

./mammoth -r 2-6

このコマンドは、スタータ・ラックのnode07から数えて6つの新しいサーバーを既存のクラスタに追加する、パラメータ・ファイルを生成します。

./mammoth -e node07 node08 node09 node10 node11 node12

10.13.1 Mammothのオプション

mammothコマンドの構文は、新しいクラスタの構成をサポートします。Mammothバンドルを使用して、以前のリリースからアップグレードすることもできます。

-c

Oracle Big Data Applianceのクラスタ・チェックを実行します。

-e newnode1 newnode2 newnode3...

クラスタに追加するサーバーのリストのパラメータ・ファイルを生成します。次に、新しいノードをクラスタに追加して、必要なソフトウェアをノードにインストールします。

同じラックまたは複数のラックにあるリストのサーバーを指定できます。

再起動は、通常は新しいノードおよび工場出荷時の初回更新時のみに実行されます。

生成されるパラメータは、opt/oracle/BDAMammoth/<cluster_name>-config.json(<cluster-name>は拡張されるクラスタの名前です)です。パラメータ・ファイルにパスワードは含まれていないため、Mammothの実行時に入力する必要があります。クラスタ拡張では、拡張でノードのデフォルトのrootパスワードが必要になるため、拡張が完了するまでそのパスワードを保持してください。パスワードは後で必ず変更してください。

Oracle NoSQL Databaseクラスタでは、Mammothにより、新しいノードのゾーンの種類を要求されます。既存のゾーン、新しいプライマリ・ゾーンまたは新しいセカンダリ・ゾーンから選択できます。既存のゾーンに追加する場合は、使用できるゾーンの一覧が表示されます。新しいゾーンを作成する場合は、ゾーンの名前およびレプリケーション・ファクタを要求されます。

注意:

Oracle Big Data Appliance 4.13においては、クラスタ拡張をKafkaクラスタに対して使用できます。
-h

コマンドの使用方法とステップのリストが含まれるコマンド・ヘルプを表示します。

-i cluster_name

クラスタですべての必須ステップを実行します。フル・ラックの場合は、-r 1-18と同じです。このオプションは、新しいラックを構成する場合や、クラスタにサーバー・グループを追加する場合に使用します。

-l

Mammothインストールのステップをリストします。

-p

クラスタのソフトウェアを最新バージョンにアップグレードするか、個別パッチをインストールします。

-r n-N

エラーが発生しないかぎり、MammothのステップnからNまでを実行します。

-s n [cluster_name]

ステップnを実行します。同じラックの別のクラスタを指定するには、cluster_nameを入力します。-eオプションを参照してください。

-v

Mammothのバージョン番号を表示します。

10.13.2 Mammothインストールのステップ

次に、ソフトウェアのインストール時にMammothが実行するステップについて説明します。

ステップ1   PreinstallChecks

このステップでは、次の複数のタスクが実行されます。

  • 構成ファイルを検証し、パスワードを要求します。

  • パスワードを入力せずに管理ネットワークのすべてのアドレスに接続できるように、rootユーザーに対してセキュア・シェル(SSH)を設定します。

  • インフィニバンド・ネットワークのrootユーザーに対してパスワードなしSSHを設定します。

  • 構成ファイルから/etc/hostsを生成し、インフィニバンド接続を使用して内部的に通信できるようにそれをすべてのサーバーにコピーします。このファイルによって、プライベートIPアドレスがパブリック・ホスト名にマップされます。

  • Mammothが実行されるノードをPuppetマスター・ノードとして識別するための別名を設定します。たとえば、IPアドレス192.168.41.1でbda1node01からMammothを実行した場合、そのIPアドレスの別名のリストにはbda1node01-masterが含まれています。Mammothでは、ソフトウェア・インストールにPuppetを使用します。

  • すべてのノードでネットワーク・タイミングを確認します。タイミング・チェックに失敗した場合、インストールの正常な実行を妨げる未解決の名前およびIPアドレスが存在します。インストールを続行する前に、これらの問題を修正してください。

このステップでは、様々なハードウェアおよびソフトウェア・チェックも実行されます。次のチェックのいずれかに失敗すると、Mammothも失敗します。

  • ARPキャッシュ問合せ時間が2秒以下であること。

  • すべてのサーバー・クロックが現在のサーバーの10秒以内で同期していること。

  • すべてのサーバーが前回の再起動に成功し、/root/BDA_REBOOT_SUCCEEDEDファイルが生成されていること。

  • bdacheckhwユーティリティが成功したこと。

  • bdacheckswユーティリティが成功したこと。

ステップ2   SetupPuppet

このステップでは、すべてのノードでPuppetエージェントを構成して起動し、Mammothが実行されているノードでPuppetマスターを構成し、エージェントが証明書を発行するのを待機してその署名を自動化します。このステップでは、すべてのノードのrootパスワードの変更も行います(オプション)。このステップが完了すると、Puppetはソフトウェアをデプロイできます。

Puppetは、Hadoopクラスタを管理するために一般的に使用される分散構成管理ツールです。Puppetマスターは、親のサービスであり、Puppetリポジトリを管理します。Puppetエージェントは、各Hadoopノードで動作します。

/etc/puppet/puppet.confという名前のファイルがすべてのサーバーに存在し、Puppetマスターの場所を指定します。

Puppetは2つのモードで動作します。

  • 定期的プル・モード: Puppetエージェントは定期的にPuppetマスターと通信し、更新の有無を確認します。

  • キック・モード: Puppetマスターは、構成の更新が使用できるというアラートをPuppetエージェントに通知し、エージェントは更新の有無を確認します。Puppetは、Mammothのインストール中はキック・モードで動作します。

どちらのモードでも、Puppetマスターは、エージェントを信頼する必要があります。この信頼を確立するため、エージェントは、システム管理プロセスによる署名が行われるPuppetマスター・ノードに証明書を送信します。このトランザクションが完了すると、Puppetマスターは、エージェントに新しい構成を送信します。

後続のステップでは、「インストール中にエラーが発生した場合の対処方法」の説明に従って、各サーバーのPuppetログ・ファイルを確認できます。

ステップ3   UpdateBaseImage

最新のOracle Big Data Applianceイメージおよびシステム・パラメータ設定をインストールします。カーネルがアップグレードされた場合、システムは自動的に再起動します。

ステップ4   PrepareBaseImage

  • ライセンス契約の要件に応じて、サード・パーティ・ライセンスをすべてのサーバーの/opt/oss/src/OSSLicenses.pdfにコピーします。

  • ライセンス契約の要件に応じて、サード・パーティ・ソフトウェアのソース・コードをすべてのサーバーの/opt/oss/src/にコピーします。

    Mammothはソース・コードをOracle NoSQL Databaseクラスタにコピーしません。

  • hdfsおよびmapredユーザーと、hadoopグループを作成します。また、oracleユーザーと、dbaおよびoinstallグループも作成します。

    後のステップでインストールされる様々なパッケージによっても、インストール中にユーザーおよびグループが作成されます。

    関連項目:

    ユーザーおよびグループの詳細は、『Oracle Big Data Applianceソフトウェア・ユーザーズ・ガイド』を参照してください。

  • NameNodeデータが設定されているディスクまたはノード全体で障害が発生した場合にこの重要な情報の損失を防ぐため、このデータを複数の場所にコピーします。

ステップ5   SetupMySQL

MySQL Databaseをインストールして構成します。このステップでは、Cloudera Managerで使用するためにnode03にプライマリ・データベースと複数のデータベースが作成されます。また、node02のバックアップ・データベースに対するプライマリ・データベースのレプリケーションも設定されます。

MammothはOracle NoSQL DatabaseクラスタにMySQL Databaseをインストールしません。

ステップ6   SetupKDC

クラスタでセキュリティを設定するために使用されるKerberosキー配布センター(KDC)を構成します。

ステップ7   InstallHadoop

Cloudera's Distribution including Apache Hadoop (CDH)およびCloudera Managerのすべてのパケットをインストールします。その後、node03でCloudera Managerサーバーを起動し、クラスタを構成します。

MammothはOracle NoSQL DatabaseクラスタにCDHまたはCloudera Managerをインストールしません。

ステップ8   StartHadoopServices

すべてのノードのエージェントを起動し、すべてのCDHサービスを開始します。HTTPS/ネットワーク暗号化が有効になっている場合は、Cloudera Manager、HueおよびOozieに対してもHTTPSを有効にします。

このステップの後、Hadoopインストール環境が完全に機能します。

Cloudera Managerは、node03のポート7180で実行されます。これは次のようにブラウザで開くことができます。

http://bda1node03.example.com:7180

この例では、bda1node02がnode02の名前で、example.comがドメインです。デフォルトのユーザー名とパスワードはadminです。パスワードはこのステップの最後に変更するように求められます。

Oracle NoSQL Databaseクラスタでは、MammothはCDHサービスをインストールも開始もしません。

ステップ9   InstallBDASoftware

Oracle Big Data Appliance構成生成ユーティリティでこのオプションを選択した場合は、Oracle Big Data Connectorsのサーバー側コンポーネントをインストールします。Oracle Big Data Connectorsにはライセンスが別途必要です。オプションです。

Oracle Big Data Appliance構成生成ユーティリティでこのオプションを選択した場合は、Oracle Big Data SQLのサーバー側コンポーネントをインストールします。Oracle NoSQL DatabaseのOracle Big Data SQLサポートの場合、このステップではCDHノードにクライアント・ライブラリ(kvclient.jar)をインストールします。Oracle Big Data SQLにはライセンスが別途必要です。オプションです。

Oracle NoSQL Databaseを使用するために割り当てられたクラスタに、Oracle NoSQL Databaseをインストールします。Enterprise Editionにはライセンスが別途必要です。

ステップ10   SetupHadoopSecurity

このステップで実行されるアクションは、インストールに先立ってOracle Big Data Appliance構成ユーティリティで行った選択に基づきます。

  • このオプションが選択されている場合は、HTTPS/ネットワーク暗号化を構成します。

  • このオプションが選択されている場合は、HDFS透過的暗号化を構成します。

    Mammothは、インストールに先立って構成ユーティリティでローカルと外部のどちらのKey Trustee Serverを選択したかに応じて、HDFS透過的暗号化に必要なNavigator Key Trusteeサービスを設定します。

    • 構成ユーティリティで「Setup Key Trustee Servers on the BDA」を選択した場合、MammothはOracle Big Data Appliance上でローカルにアクティブおよびパッシブKey Trustee Serverを設定します。

    • 外部Key Trustee Serverを使用するように選択した場合、この設定で外部サーバーへの接続が構成されます(MOS Doc ID 2112644.1の説明に従って外部Navigator Key Trustee Serverがすでに構成されている必要があります)。

  • このオプションを選択した場合には、Kerberos認証を構成します。Oracle Big Data Applianceでキー配布センターを設定している場合には、前提条件はありません。それ以外の場合には、「インストールの前提条件」を参照してください。

ステップ11   SetupASR

自動サービス・リクエスト(ASR)をインストールして構成します。オプションです。

このステップでは、次のことが実行されます。

  • 必要なソフトウェア・パッケージをインストールします。

  • トラップ宛先を構成します。

  • 監視デーモンを起動します。

ASRマネージャからアセットをアクティブ化するには、「ASRアセットの確認」を参照してください。

注意:

このステップを正常に実行するには、ASRマネージャが実行され、適切に構成されたASRホスト・システムが稼働している必要があります。「自動サービス・リクエストの設定」を参照してください。

ステップ12   CleanupInstall

次のことが実行されます。

  • Cloudera Managerパスワードを変更します(インストール・テンプレートに指定されている場合)。

  • インストール中に作成された一時ファイルを削除します。

  • すべてのノードから/opt/oracle/bda/install/logのサブディレクトリにログ・ファイルをコピーします。

  • クラスタ検証チェック(TeraSortを含む)を実行して、すべてが適切に動作することを確認します。また、インストール・サマリーも生成されます。すべてのログは、node01の/opt/oracle/bda/install/log以下のサブディレクトリに格納されます。

ステップ13   CleanupSSHroot (オプション)

「PreinstallChecks」で設定したrootのパスワードなしSSHを削除します。

10.14 Oracle Big Data Applianceベース・イメージ・ユーティリティ

次のユーティリティは、ベース・イメージのバンドルで配布されています。ユーティリティを実行するには、rootとしてログインする必要があります。

10.14.1 makebdaimage

単一のサーバー、クラスタ、またはラック全体にベース・イメージを再インストールします。reimageclusterとreimagerackのどちらもこのユーティリティを呼び出します。

makebdaimageユーティリティには次の構文があります。 

makebdaimage [--usb | --usbint] [--noiloms] /path/BDABaseImage-version_RELEASE.iso /path/BDdaDeploy.json target_servers

オプション

--usb | --usbint

イメージの変更に使用するUSBポートを指定します。外部USBドライブの場合は--usb、内部ドライブの場合は--usbintを使用します。内部USBドライブにはLinuxの完全インストールが含まれます。

--usbintオプションを使用するには、ターゲット・サーバーにログインしている必要があります。ログインしていないと、間違ったネットワーク情報を使用してサーバーのイメージを変更する可能性があります。

--noiloms

イメージの変更処理によって、ターゲット・サーバー上のOracle ILOMが変更されることはありません。

target_servers

イメージをインストールする1つ以上のサーバーを示し、次のいずれかの書式で指定します。

  • node_number

    イメージを変更する単一のサーバーを指定します。サーバーのラック上の位置を下から数えて1から18で入力します。

  • from.json to.json

    現在の構成(from.json)と必要な構成(to.json)を指定します。JSONファイルは、BdaShip.jsonの工場出荷時の構成またはnetwork.jsonのカスタム構成のいずれでもかまいません。構成されたサーバーの/opt/oracle/bdaにあります。

  • to.json: network.jsonやBdaShip.jsonに類似の連結されたJSONファイルですが、ETH0_MACSアレイ・エントリが追加されています。連結ファイルの最初のエントリと対応するeth0_macエントリがイメージを変更するときに使用されます。to.jsonファイルはそのまま使用されます。

10.14.2 reimagecluster

dcliとmakebdaimageを使用して、クラスタ内のすべてのサーバーのイメージを同時に変更します。

reimageclusterユーティリティには次の構文があります。 

reimagecluster [--no-iloms]

前提条件

  • 次のコマンドがクラスタ内のサーバーのリストを返すことを確認します。

    $ dcli -C hostname

  • BDABaseImage-version_RELEASE*.isoファイルが現在のディレクトリに1つだけあることを確認します。

オプション

--no-iloms

イメージの変更処理によって、ターゲット・サーバー上のOracle ILOMが変更されることはありません。

10.14.3 reimagerack

dcliとmakebdaimageを使用して、ラック内のすべてのサーバーのイメージを同時に変更します。

reimagerackユーティリティには次の構文があります。 

reimagerack [--no-iloms] [--no-macs] [--hosts n1, n2...] [from.json [to.json]]

前提条件

  • 次のコマンドがラック内のサーバーのリストを返すことを確認します。

    $ dcli -hostname

  • BDABaseImage-version_RELEASE*.isoファイルが現在のディレクトリに1つだけあることを確認します。

オプション

--no-iloms

イメージの変更処理によって、ターゲット・サーバー上のOracle ILOMが変更されることはありません。

--no-macs

このユーティリティはサーバーのMACアドレスを取得しません。かわりに、インフィニバンドのケーブル配線を使用します。このオプションは、工場出荷時の設定を復元する場合にのみ使用します。コマンドラインに両方のJSONファイル(from.jsonとto.json)が含まれている必要があります。

--hosts n1, n2...

ホスト名またはIPアドレスのカンマ区切りのリストのうち、dcliが受け入れたいずれかのリストで指定されたサーバーのイメージの変更を制限します。すべてのサーバーは、dcli -tコマンドで指定されたターゲット・サーバーのリストに含まれている必要があります。

このオプションでは--no-macsオプションが強制的に実行されるため、その制限も適用されます。

from.json

現在の構成ファイル(BdaShip.jsonまたはnetwork.json)へのフルパスです。

このオプションのデフォルト値は、/opt/oracle/bda/network.jsonです。network.jsonが見つからない場合、オプションのデフォルト値は、/opt/oracle/bda/BdaShip.jsonです。サーバーは事前にreimagerackで使用されているJSONファイルの値に設定されている必要があります。

to.json

イメージの変更後に有効になる新しいネットワーク構成へのフルパスです。network.jsonファイルまたはBdaShip.jsonファイルのいずれかになります。