ヘッダーをスキップ

Oracle® Big Data Applianceオーナーズ・ガイド リリース4 (4.0) E57726-01 |
| 目次 | 索引

前 | 次 |

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

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

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

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

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

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

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

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

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

- オプション・ソフトウェアの構成の変更

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

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

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

- Mammoth再構成ユーティリティの構文

- 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のラックに複数のクラスタを作成できます。

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

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

- ネットワーク暗号化、ディスク暗号化、Kerberos、Sentry、Oracle Audit Vault and Database Firewallおよび自動サービス・リクエストなどのオプション・サービスを構成および削除できます。

- Oracle Big Data Appliance用Oracle Enterprise Managerシステム監視プラグインをデプロイまたは削除できます。

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

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

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

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

Audit Vaultの要件:

- Oracle Big Data Applianceと同じネットワーク上の別のサーバーで、Oracle Audit Vault and Database Firewall Serverリリース12.1.1以上が稼働している必要があります。

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

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

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

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

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

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

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

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

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

リモートKDCの場合の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が正常に動作しないことがあります。

Sentryの前提条件

1. `sentry-provider.ini`という名前のSentryポリシー・ファイルを作成します。

2. そのファイルをクラスタの第1ノード上の`/opt/oracle/BDAMammoth`にコピーします。

   関連項目: ポリシー・ファイルの作成の詳細は、次のURLにあるCDH5 Security GuideのSentryの構成に関する項を参照してください。 `http://www.cloudera.com/content/cloudera-content/cloudera-docs/CDH5/latest/CDH5-Security-Guide/cdh5sg_sentry.html?scroll=concept_mm2_21p_wk_unique_1`

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

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

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

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

1. Oracle Automated Release Updates (ARU)のウェブサイトにあるダウンロード・サイトの場所を確認します。次のパッチがOracle Big Data Appliance 3.0用です。

   - 新規インストールおよびOracle Linux 6クラスタへのアップグレード:

     `http://aru.us.oracle.com:8080/ARU/ViewPatchRequest/process_form?aru=17562359`

   - Oracle Linux 5クラスタへのアップグレード:

     `http://aru.us.oracle.com:8080/ARU/ViewPatchRequest/process_form?aru=17562358`

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

   パッチは、次の2つのファイルで構成されます。

   - `p` `patch_version``_Linux-x86-64_1of2.zip`にはMammothインストール・ファイルが含まれます。

   - `p` `patch_version``_Linux-x86-64_2of2.zip`にはベース・イメージが含まれています。

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

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

       $ unzip p12345678_300_Linux-x86-64_1of2.zip
       Archive:  p12345678_300_Linux-x86-64_1of2.zip
         inflating: README.txt
          creating: BDAMammoth-ol6-3.0.0/
         inflating: BDAMammoth-ol6-3.0.0/BDAMammoth-ol6-3.0.0.run

       $ unzip p12345678_300_Linux-x86-64_2of2.zip
       Archive:  p12345678_300_Linux-x86-64_2of2.zip
          creating: BDABaseImage-ol6-3.0.0_RELEASE/
         inflating: BDABaseImage-ol6-3.0.0_RELEASE/biosconfig
         inflating: BDABaseImage-ol6-3.0.0_RELEASE/reimagecluster
         inflating: BDABaseImage-ol6-3.0.0_RELEASE/reimagerack
         inflating: BDABaseImage-ol6-3.0.0_RELEASE/makebdaimage
         inflating: BDABaseImage-ol6-3.0.0_RELEASE/BDABaseImage-ol6-3.0.0_RELEASE.iso
         inflating: BDABaseImage-ol6-3.0.0_RELEASE/README.txt
        extracting: BDABaseImage-ol6-3.0.0_RELEASE/BDABaseImage-ol6-3.0.0_RELEASE.md5sum
         inflating: BDABaseImage-ol6-3.0.0_RELEASE/ubiosconfig

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

       # cd BDAMammoth-ol6-3.0.0

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

       # ./BDAMammoth-ol6-3.0.0.run

       Big Data Appliance Mammoth v3.0.0 Self-extraction

       Checking for and testing BDA Base Image in /tmp

       BDABaseImage-3.0.0_RELEASE.iso: OK

       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 Base Image RPMs to bdarepo
       Moving BDABaseImage into /opt/oracle/

       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クラスタを実行できます。

ユーザーのインストール環境に合わせて適切な手順を実行します。

- 1つ以上のクラスタを構成する単一のOracle Big Data Applianceラックの場合は、「単一ラックまたはプライマリ・ラックへのソフトウェアのインストール」の手順に従います。

- 各ラックが独立したクラスタを構成する複数ラックの場合は、ラックごとに「単一ラックまたはプライマリ・ラックへのソフトウェアのインストール」の手順を実行します。

- 単一のマルチラック・クラスタを構成する複数ラックの場合は、次のようになります。

  - クラスタのプライマリ・ラックを識別して、「単一ラックまたはプライマリ・ラックへのソフトウェアのインストール」の手順に従います。

  - クラスタのその他のラックの場合は、「クラスタへのサーバーの追加」の手順に従います。

### 10.4.1 単一ラックまたはプライマリ・ラックへのソフトウェアのインストール

次の手順に従って、単一のOracle Big Data Applianceラックまたは複数ラック・クラスタのプライマリ・ラックにソフトウェアをインストールして構成します。

単一ラックまたはプライマリ・ラックにソフトウェアをインストールするには、次の手順を実行します。

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

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

3. 「Mammothソフトウェア・デプロイメント・バンドルのダウンロード」の説明に従って、Mammothバンドルをダウンロードして解凍します。クラスタの第1サーバーに`root`としてログインしている必要があります。

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

       # cd /opt/oracle/BDAMammoth

5. `cluster_name``-config.json`を現在のディレクトリにコピーします。「構成ファイルについて」を参照してください。

6. 適切なオプションを使用して`mammoth`コマンドを実行します。「Mammothソフトウェア・インストールおよび構成ユーティリティ」を参照してください。このサンプル・コマンドはすべての手順を実行します。

       ./mammoth -i rack_name

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 1450112.1のASREXACHECKによるASR Exadataの構成チェックに関するドキュメントを検索し、`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

   `dcli`の詳細は、第14章を参照してください。

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 クラスタへのサーバーの追加

3つのサーバーのグループに分けられた既存のクラスタにサーバーを追加できます。フル・ラックは、少数のサーバーを追加する場合と同じように追加します。ただし、Oracle Big Data Appliance構成生成ユーティリティで構成ファイルは生成されません。かわりに、Mammothを使用して構成ファイルを生成し、それを使用してサーバーを構成します。

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

1. すべてのサーバーで同じソフトウェア・バージョンが実行されていることを確認します。「ソフトウェア・バージョンの違いについて」を参照してください。

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

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

       cd /opt/oracle/BDAMammoth

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

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

       ./mammoth -e node13 node14 node15 node16 node17 node18

   同じラックまたは複数のラックにあるサーバーを指定できます。「Mammothソフトウェア・インストールおよび構成ユーティリティ」で`-e`オプションを参照してください。

5. 拡張番号の入力を求められた場合は、1から5の整数を入力します。

6. ソフトウェアをインストールします。次の例では、拡張番号が1のbda3のサーバーでソフトウェアのインストールを開始します。

       ./mammoth -i bda3 1

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

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

- `-p`オプションを使用してMammothを実行し、クラスタのソフトウェアを最新バージョンにアップグレードします。「Oracle Big Data Applianceでのソフトウェアのアップグレード」を参照してください。

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

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

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

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

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

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

1. エラー・メッセージを読んで、原因または解決策が示されているかどうかを確認します。

2. 推奨される変更を行い、手順を再実行します。

3. エラー・メッセージに解決策が示されていない場合、または問題が解決されない場合:

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

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

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

## 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 Linux 5用とOracle Linux 6用に、2つのバージョンのソフトウェア・バンドルを使用できます。

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

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

注意: アップグレード・プロセスでは必要に応じてサービスが自動的に停止および開始されるため、クラスタは`mammoth`コマンドの実行中は使用できません。

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

Oracle Big Data Appliance 2.3以上のソフトウェアは、Oracle Linuxバージョン5またはバージョン6で動作します。ソフトウェアをアップグレードする際、オペレーティング・システムもアップグレードするかどうか選択できます。

- Oracle Linux 5を維持: Oracle Linux 5用のMammothバンドルをダウンロードします。Oracle Linux 5を維持しますが、Oracle Unbreakable Enterprise Kernel (UEK)をバージョン2にアップグレードします。このリリースのすべてのOracle Big Data Applianceソフトウェアをインストールします。

- Oracle Linux 6にアップグレード: Oracle Linux 6用のMammothバンドルをダウンロードします。オペレーティング・システムをアップグレードするには、まずサーバーのイメージを変更する必要があります。イメージを変更するとすべてのファイルとデータが消去されるため、同じデータを使用するバックアップとして2つ目のクラスタが機能している場合を除いて、本番システムに対してはこのタイプのアップグレードをお薦めしません。イメージの変更が終わると、Oracle Linux 6とUEKバージョン2を使用してソフトウェアをインストールできます。

### 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エージェントがインストールされている場合)

#### 10.7.2.2 現在のソフトウェア・バージョンへのアップグレード

Oracle Big Data Applianceソフトウェアを現在のソフトウェア・バージョンにアップグレードするには、次の手順を実行します。

1. Oracle Big Data Applianceソフトウェアの旧バージョンを実行している場合は、システムをバージョン2.5にアップグレードします。

2. 「Mammothソフトウェア・デプロイメント・バンドルのダウンロード」の説明に従って、Mammothバンドルをダウンロードして解凍します。クラスタの第1サーバーに`root`としてログインしている必要があります。

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

       # cd /opt/oracle/BDAMammoth

4. `-p`オプションを使用して`mammoth`コマンドを実行します。

       # ./mammoth -p

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

## 10.8 オプション・ソフトウェアの構成の変更

Oracle Big Data Applianceの初期構成中に、オプションのソフトウェア・コンポーネントがインストールされる場合とインストールされない場合があります。Mammoth再構成ユーティリティを使用して、この決定の一部を逆にすることができます。関係のあるサーバー名、ポート、ユーザー名およびパスワードを指定する必要があります。「Mammoth再構成ユーティリティの構文」を参照してください。

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

- Oracle Big Data Connectorsのサポートの変更

- 自動サービス・リクエストのためのサポートの追加

- Oracle Enterprise Manager Cloud Controlのサポートの追加

- Oracle Audit Vault and Database Firewallのサポートの追加

- ディスク暗号化の追加

- Kerberos認証の追加

注意: `bdacli`コマンドは、`mammoth-reconfig`を呼び出す別の構文を提供します。「bdacli」を参照してください。

### 10.8.1 Oracle Big Data Connectorsのサポートの変更

Oracle Big Data Connectorsのサポートを追加または削除できます。

#### 10.8.1.1 Oracle Big Data Connectorsの追加

Oracle Big Data Connectorsのサポートを追加するとき、Oracle Data Integrator Application Adapter for Hadoopをインストールするかどうかを選択できます。インストールする場合は、MySQL DatabaseのrootユーザーおよびOracle Data Integratorユーザー(`BDA_ODI_REPO`)のパスワードを指定する必要があります。また、次のパスワードが`cluster_name``-config.json`に保存されていない場合は、それらのパスワードを用意する必要があります。

- Cloudera Managerのadminユーザー

- Oracle Audit Vault and Database Firewall (有効になっている場合)

次の手順では、`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: The password for audit vault server is not needed since feature is not enabled
       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.8.1.2 Oracle Big Data Connectorsの削除

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

- Cloudera Managerのadminユーザー

- MySQL Databaseのrootユーザー(Oracle Data Integrator Application Adapter for Hadoopが有効になっている場合)

- MySQL DatabaseのBDA_ODI_REPOユーザー(Oracle Data Integrator Application Adapter for Hadoopが有効になっている場合)

- Oracle Audit Vault and Database Firewall (有効になっている場合)

次の手順では、`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: The password for audit vault server is not needed since feature is not enabled
       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.8.2 自動サービス・リクエストのためのサポートの追加

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

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

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

2. プライマリ・ラックの第1 NameNode (node01)に`root`としてログインし、`BDAMammoth`ディレクトリに移動します。

       cd /opt/oracle/BDAMammoth

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

       # cd /opt/oracle/BDAMammoth
       # ./mammoth-reconfig add 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 ...
            .
            .
            .

4. 「自動サービス・リクエストのインストールの確認」の手順を完了します。

### 10.8.3 Oracle Enterprise Manager Cloud Controlのサポートの追加

次の手順では、Oracle Enterprise Manager Cloud Controlに対するサポートの追加方法について示します。

Oracle Enterprise Manager Cloud Controlをサポートするには、次の手順を実行します。

1. 同じネットワーク上のOracle Enterprise Manager Cloud ControlインストールにOracle Big Data Appliance用のシステム監視プラグインをインストールします。『Oracle Enterprise Manager System Monitoring Plug-inインストレーション・ガイドfor Oracle Big Data Appliance』を参照してください。

2. プライマリ・ラックの第1 NameNode (node01)にログインし、`BDAMammoth`ディレクトリに移動します。

       cd /opt/oracle/BDAMammoth

3. Oracle Enterprise Manager Cloud Controlに対するサポートを追加します。

       # cd /opt/oracle/BDAMammoth
       # ./mammoth-reconfig add em
       INFO: Logging all actions in /opt/oracle/BDAMammoth/bdaconfig/tmp/bda1node01-20130205082218.log and traces in /opt/oracle/BDAMammoth/bdaconfig/tmp/bda1node01-20130205082218.trc
            .
            .
            .
       Enter the value for EM_HOST [Default:]: oem-host.example.com
       Enter the value for EM_PORT [Default: 4473]:
       Enter the value for EM_USER [Default: sysman]:

       Please Check the values you entered for the EM parameters

       EM_HOST = oem-host.example.com
       EM_PORT = 4473
       EM_USER = sysman

       Are these values correct (y/n): y
       Enter password for user sysman on machine oem-host.example.com
       Enter password: password
       Enter password again: password
       Enter agent registration password for em setup on machine oem-host.example.com
       Enter password: password
       Enter password again: password
       INFO: Checking passwordless ssh setup
       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.
       INFO: Creating environment.pp file ...
       INFO: Making sure all puppet agents can be accessed.
       INFO: Pinging puppet agents
       INFO: Creating directories for em download This will take some time ...
            .
            .
            .

### 10.8.4 Oracle Audit Vault and Database Firewallのサポートの追加

Oracle Big Data Applianceのサポートをインストールする前に、Oracle Audit Vault and Database Firewall Serverリリース 12.1.1以上のバージョンが稼働していることを確認します。Oracle Big Data Applianceと同じネットワーク上の別のサーバーにインストールする必要があります。

また、Audit Vault Serverのインストールに関する次の情報が必要になります。

- Audit Vault Serverの管理ユーザー名とパスワード

- データベース・サービス名

- IPアドレス

- ポート番号

- Oracle Big Data Applianceのディスク暗号化(有効になっている場合)のパスワード

Oracle Audit Vault and Database Firewallのサポートを追加する場合:

1. プライマリ・ラックの第1 NameNode (node01)にログインし、`BDAMammoth`ディレクトリに移動します。

       # cd /opt/oracle/BDAMammoth

2. Oracle Audit Vault and Database Firewallのサポートを追加します。

       # ./mammoth-reconfig add auditvault
       INFO: Logging all actions in /opt/oracle/BDAMammoth/bdaconfig/tmp/ bda1node01-20140805072714.log and traces in /opt/oracle/BDAMammoth/bdaconfig/tmp/ bda1node01-20140805072714.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...
       Please enter the Audit Vault Server Admin Username: admin_username
       Please enter the Audit Vault Server Admin Password: admin_password
       Enter password again: admin_password
       Please enter the Audit Vault Server Database Service Name: service_name
       Please enter the Audit Vault Server IP Address: IP address
       Please enter the Audit Vault Server Port: port_number
       INFO: The password for disk encryption is not needed since feature is not enabled
       INFO: Creating environment.pp file ...
       INFO: Making sure all puppet agents can be accessed.
       INFO: Pinging puppet agents
       INFO: Adding audit Vault Service. This will take some time ...
            .
            .
            .

### 10.8.5 ディスク暗号化の追加

ディスク暗号化は、次の手順で構成します。インストール後、サービスが正常に動作していることを確認するための一連のテストが実行されます。

パスワードを変更するには、`mammoth-reconfig update`コマンドを使用します。

ディスク暗号化をサポートするには、次の手順を実行します。

1. プライマリ・ラックの第1 NameNode (node01)にログインし、`BDAMammoth`ディレクトリに移動します。

       cd /opt/oracle/BDAMammoth

2. ディスク暗号化を有効にします。

       # bdacli enable disk_encryption
       INFO: Logging all actions in /opt/oracle/BDAMammoth/bdaconfig/tmp/bda1node01-20140805084442.log and traces in /opt/oracle/BDAMammoth/bdaconfig/tmp/                 bda1node01-20140805084442.trc
       INFO: This is the install of the primary rack
       INFO: Checking if password-less ssh is set up
            .
            .
            .
        Enter password for encrypting disks: password
        Enter password again: password
       INFO: The password for audit vault server is not needed since feature is not enabled
       INFO: Making sure all puppet agents can be accessed.
       INFO: Pinging puppet agents ..
       INFO: Shutting down Cloudera Manager server/agents. This will take some time ...
            .
            .
            .
       INFO: Executing setup_disk_encryption.sh on nodes

       /opt/oracle/BDAMammoth/bdaconfig/tmp/all_nodes #Step -1#
       SUCCESS: Executed setup_disk_encryption.sh on nodes

       /opt/oracle/BDAMammoth/bdaconfig/tmp/all_nodes #Step -1#
       SUCCESS: Successfully setup disk encryption on the cluster
            .
            .
            .
       INFO: Starting Hadoop Services. This will take some time ...
            .
            .
            .

       INFO: Doing post-cleanup operations
       INFO: Running cluster validation checks and generating install summary
       Enter CM admin password to enable check for CM services and hosts
       Press ENTER twice to skip CM services and hosts checks
       Enter password: Enter
       Enter password again: Enter
       INFO: No Cloudera Manager password given. Skipping Cloudera Manager health checks
       Checking Cluster Type
       Checking if Kerberos enabled
       Retrieving Cluster Information

       Running Cluster Health Checks (bdacheckcluster)
       Warning: Permanently added 'bda1node01-master' (RSA) to the list of known hosts.
       INFO: No Cloudera Manager password given - Cloudera Manager health checks skipped

       Running 1 GB teragen-terasort-teravalidate Hadoop Validation Test
       teragen         : 29 s
       terasort        : 36 s
       teravalidate    : 33 s
       -----------------------------
       Total time       : 98 s

       Status : succeeded

       Running An Oozie Workflow Test
       oozie passed
       oozie workflow test finished in 267 seconds

       Map Reduce Job Status:
       0000000-140805085424212-oozie-oozi-W@mr-node OK job_1407254020699_0012

       SUCCEEDED -
       Pig Job Status:
       0000000-140805085424212-oozie-oozi-W@pig-node OK job_1407254020699_0004

       SUCCEEDED -
       Hive Job Status:
       0000000-140805085424212-oozie-oozi-W@hive-node OK job_1407254020699_0006

            .
            .
            .
       SUCCESS: Cluster validation checks were all successful
       INFO: Time spent in post-cleanup operations is 1051 seconds.
       ==================================================================================

       INFO: Please download the install summary zipfile from /tmp/bda1cdh-install-summary.zip

### 10.8.6 Kerberos認証の追加

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

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

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

2. プライマリ・ラックの第1 NameNode (node01)にログインし、`BDAMammoth`ディレクトリに移動します。

       cd /opt/oracle/BDAMammoth

3. Kerberosを構成します。

       # ./mammoth-reconfig add 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#
            .
            .
            .

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

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

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

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

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

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

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

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

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

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

1. My Oracle SupportまたはOracle Automated Release Updates (ARU)からベース・イメージ・パッチをダウンロードして、イメージを変更するサーバーにコピーします。Mammothバンドルと一緒にダウンロードしたベース・イメージを使用するか、個別のベース・イメージ・パッチをダウンロードできます。

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

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

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

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 p19070502_260_Linux-x86-64.zip
       Archive:  p19070502_260_Linux-x86-64.zip
          creating: BDABaseImage-ol6-2.6.0_RELEASE/
         inflating: BDABaseImage-ol6-2.6.0_RELEASE/biosconfig
         inflating: BDABaseImage-ol6-2.6.0_RELEASE/makebdaimage
         inflating: BDABaseImage-ol6-2.6.0_RELEASE/reimagerack
         inflating: BDABaseImage-ol6-2.6.0_RELEASE/reimagecluster
        extracting: BDABaseImage-ol6-2.6.0_RELEASE/BDABaseImage-ol6-2.6.0_RELEASE.md5sum
         inflating: BDABaseImage-ol6-2.6.0_RELEASE/BDABaseImage-ol6-2.6.0_RELEASE.iso
          creating: BDABaseImage-ol6-2.6.0_RELEASE/Extras/
          creating: BDABaseImage-ol6-2.6.0_RELEASE/Extras/RCU/
         inflating: BDABaseImage-ol6-2.6.0_RELEASE/Extras/RCU/rcuintegration-11.1.1.7.0-1.x86_64.rpm
          creating: BDABaseImage-ol6-2.6.0_RELEASE/Extras/ODI/
         inflating: BDABaseImage-ol6-2.6.0_RELEASE/Extras/ODI/odiagent-11.1.1.7.0-1.x86_64.rpm
         inflating: BDABaseImage-ol6-2.6.0_RELEASE/README.txt
         inflating: BDABaseImage-ol6-2.6.0_RELEASE/ubiosconfig

5. 前の手順で作成したサブディレクトリに移動します。

       $ cd BDABaseImage-ol6-2.6.0_RELEASE

6. `makebdaimage`コマンドを使用してサーバーのイメージを変更します。次の例では、内部USBを含めたサーバー4のイメージを、2.6.0ベース・イメージから`BdaDeploy.json`のカスタム設定に変更しています。イメージを変更するサーバー(この例では、サーバー4)にログインしている必要があります。

       ./makebdaimage --usbint BDABaseImage-ol6-2.6.0_RELEASE.iso /opt/oracle/bda/BdaDeploy.json 4

   コマンドの完全な構文は、`makebdaimage`を参照してください。

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

### 10.9.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バンドルと一緒にダウンロードしたベース・イメージを使用するか、個別のベース・イメージ・パッチをダウンロードできます。

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

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

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

4. 既存のカスタマ・ネットワーク設定のイメージを再適用するには、意図したネットワーク構成が`/opt/oracle/bda/BdaDeploy.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 p19070502_260_Linux-x86-64.zip
        Archive:  p19070502_260_Linux-x86-64.zip
           creating: BDABaseImage-ol6-2.6.0_RELEASE/
          inflating: BDABaseImage-ol6-2.6.0_RELEASE/biosconfig
          inflating: BDABaseImage-ol6-2.6.0_RELEASE/makebdaimage
          inflating: BDABaseImage-ol6-2.6.0_RELEASE/reimagerack
          inflating: BDABaseImage-ol6-2.6.0_RELEASE/reimagecluster
         extracting: BDABaseImage-ol6-2.6.0_RELEASE/BDABaseImage-ol6-2.6.0_RELEASE.md5sum
          inflating: BDABaseImage-ol6-2.6.0_RELEASE/BDABaseImage-ol6-2.6.0_RELEASE.iso
           creating: BDABaseImage-ol6-2.6.0_RELEASE/Extras/
           creating: BDABaseImage-ol6-2.6.0_RELEASE/Extras/RCU/
          inflating: BDABaseImage-ol6-2.6.0_RELEASE/Extras/RCU/rcuintegration-11.1.1.7.0-1.x86_64.rpm
           creating: BDABaseImage-ol6-2.6.0_RELEASE/Extras/ODI/
          inflating: BDABaseImage-ol6-2.6.0_RELEASE/Extras/ODI/odiagent-11.1.1.7.0-1.x86_64.rpm
          inflating: BDABaseImage-ol6-2.6.0_RELEASE/README.txt
          inflating: BDABaseImage-ol6-2.6.0_RELEASE/ubiosconfig

11. 前の手順で作成したサブディレクトリに移動します。

        $ cd BDABaseImage-ol6-2.6.0_RELEASE

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

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

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

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

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

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

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

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

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

             ./reimagerack deploy ship

    コマンドの完全な構文は、`reimagerack`を参照してください。

13. Mammothを実行します。「単一ラックまたはプライマリ・ラックへのソフトウェアのインストール」を参照してください。

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

この手順を実行して、Mammothユーティリティがクラスタとしてデプロイしたサーバー・グループのイメージを変更します。既存のネットワーク設定は、イメージの変更後に自動的に再適用されます。

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

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

1. Oracle Big Data Appliance以外の安全な場所に`/opt/oracle/BDAMammoth/``cluster_name``-config.json`ファイルを保存します。

2. My Oracle SupportまたはOracle Automated Release Updates (ARU)から最新のベース・イメージ・パッチをダウンロードして、イメージを変更するクラスタの第1サーバーにコピーします。ファイルは任意のディレクトリにコピーできます(`/tmp`など)。

   Mammothバンドルと一緒にダウンロードしたベース・イメージを使用するか、個別のベース・イメージ・パッチをダウンロードできます。

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

   ラック内のクラスタの構成に応じて、第1サーバーは下から数えて1番目、7番目、10番目または13番目になる場合があります。

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

4. 意図したネットワーク構成が`/opt/oracle/bda/BdaDeploy.json`に反映されていることを確認します。反映されていない場合は、Oracle Big Data Appliance構成生成ユーティリティを使用して新しいファイルを生成します。「構成ファイルの生成」を参照してください。

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

       # dcli -C 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 -C hostname`コマンドが正常に実行されるまで、作業を継続しないでください。

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

       # dcli -C bdacheckhw | grep -v SUCCESS

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

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

9.     # dcli -C 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ファイルを解凍します(2/2)。次に例を示します。

        $ unzip p19070502_260_Linux-x86-64_2of2.zip
        Archive:  p19070502_260_Linux-x86-64_2of2.zip
           creating: BDABaseImage-ol6-2.6.0_RELEASE/
          inflating: BDABaseImage-ol6-2.6.0_RELEASE/biosconfig
          inflating: BDABaseImage-ol6-2.6.0_RELEASE/reimagecluster
          inflating: BDABaseImage-ol6-2.6.0_RELEASE/reimagerack
          inflating: BDABaseImage-ol6-2.6.0_RELEASE/makebdaimage
          inflating: BDABaseImage-ol6-2.6.0_RELEASE/BDABaseImage-ol6-2.6.0_RELEASE.iso
          inflating: BDABaseImage-ol6-2.6.0_RELEASE/README.txt
         extracting: BDABaseImage-ol6-2.6.0_RELEASE/BDABaseImage-ol6-2.6.0_RELEASE.md5sum
          inflating: BDABaseImage-ol6-2.6.0_RELEASE/ubiosconfig

11. 前の手順で作成したサブディレクトリに移動します。

        $ cd BDABaseImage-ol6-2.6.0_RELEASE

12. クラスタのイメージを変更します。

        ./reimagecluster

    コマンドの完全な構文は、reimageclusterを参照してください。

13. Mammothを実行します。「単一ラックまたはプライマリ・ラックへのソフトウェアのインストール」を参照してください。

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

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

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

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

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

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

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

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

       $ cd BDA-patch-2.2.1-123456

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

       $ ./BDA-patch-2.2.1-123456.run
       Big Data Appliance one-off patch 123456 for v2.2.1 Self-extraction

       Removing existing temporary files

       Generating /tmp/BDA-patch-2.2.1-123456.tar
       Verifying MD5 sum of /tmp/BDA-patch-2.2.1-123456.tar
       /tmp/BDA-patch-2.2.1-123456.tar MD5 checksum matches

       Extracting /tmp/BDA-patch-2.2.1-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

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

## 10.11 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

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

    ./mammoth -r 2-6

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

    ./mammoth -e node07 node08 node09 node10 node11 node12

### 10.11.1 Mammothのオプション

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

-c

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

-e newnode1, newnode2, newnode3...

  クラスタに追加するサーバー・グループのパラメータ・ファイルを生成します。新しいサーバーがクラスタ外のラックにある場合、ファイル名は`cluster_name``-config.json`になります。そうではない場合、Mammothは1から5のラック内拡張番号の入力を求め、名前に使用します(mammoth-bda1-1など)。

  新しいサーバーを指定するには、それらをコマンドラインにリストします。同じラックまたは複数のラックにあるサーバーを指定できます。

  パラメータ・ファイルにパスワードは含まれていないため、Mammothの実行時に入力する必要があります。

-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.11.2 Mammothインストールのステップ

次に、ソフトウェアのインストール時に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 PatchFactoryImage

  最新のOracle Big Data Applianceイメージおよびシステム・パラメータ設定をインストールします。

ステップ4 CopyLicenseFiles

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

ステップ5 CopySoftwareSource

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

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

ステップ6 CreateLogicalVolumes

  MammothはOracle NoSQL Databaseクラスタの論理ボリュームを作成しません。

ステップ7 CreateUsers

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

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

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

ステップ8 SetupMountPoints

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

ステップ9 SetupMySQL

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

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

ステップ10 InstallHadoop

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

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

ステップ11 StartHadoopServices

  すべてのノードのエージェントを起動し、すべてのCDHサービスを開始します。このステップの後、Hadoopインストール環境が完全に機能します。

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

      http://bda1node03.example.com:7180

  この例では、bda1node02がnode02の名前で、`example.com`がドメインです。デフォルトのユーザー名とパスワードは、`admin`です(これはステップ17で変更されます)。

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

ステップ12 InstallBDASoftware

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

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

ステップ13 HadoopDataEncryption

  ネットワークおよびディスクの暗号化を構成します。

ステップ14 SetupKerberos

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

ステップ15 SetupEMAgent

  Oracle Enterprise Managerエージェントをインストールして構成します。オプションです。

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

  - 「次の名前付き資格証明を作成します: 「スイッチ資格証明」、「ホスト資格証明」、「Cloudera Managerの資格証明」、「ILOM資格証明」

    クラスタ拡張では、同じ資格証明が再使用されます。

  - Oracle Big Data ApplianceサーバーのOracle Big Data ApplianceおよびOracle Exadata Database Machineプラグイン・エージェントを管理サーバーにデプロイされた最新バージョンに更新します。

  - 名前付き資格証明を使用してクラスタの検出を実行します。

  注意: この手順を正常に実行するには、Oracle Management Systemが稼働している必要があります。『Oracle Enterprise Manager System Monitoring Plug-inインストレーション・ガイドfor Oracle Big Data Appliance』を参照してください。

ステップ16 SetupASR

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

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

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

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

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

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

  注意: このステップを正常に実行するには、ASRマネージャが実行され、適切に構成されたASRホスト・システムが稼働している必要があります。第5章を参照してください。

ステップ17 CleanupInstall

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

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

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

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

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

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

  ステップ1で設定した`root`のパスワードなしSSHを削除します。

## 10.12 Mammoth再構成ユーティリティの構文

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

    ./mammoth-reconfig option parameter

注意: ここで、parameterは構文例のノード名、`bda1`はラック名、`node`はサーバー・ベース名、`-adm`は管理アクセスの接尾辞です。 このユーティリティは、`/opt/oracle/bda/install/state/config.json`に格納されている構成設定を使用します。ユーティリティで変更が行われると、このファイルが変更されて新しい構成が反映されます。 `bdacli`コマンドは、`mammoth-reconfig`を呼び出す別の方法を提供します。「bdacli」を参照してください。

オプション

add | remove

  クラスタに対してサービスを追加または削除します。

  次の例では、クラスタ内のすべてのサーバーに自動サービス・リクエスト・サポートを追加します。

      # cd /opt/oracle/BDAMammoth
      # ./mammoth-reconfig add asr

  次の例では、クラスタ内のすべてのサーバーからOracle Enterprise Managerサポートを削除します。

      # cd /opt/oracle/BDAMammoth
      # ./mammoth-reconfig remove em

  表10-1では、`add`および`remove`の有効なパラメータであるキーワードについて説明します。

  Table 10-1 Mammoth再構成ユーティリティのADDおよびREMOVEのキーワード

  コンポーネント・キーワード | 説明
  --- | ---
  `asr` | 自動サービス・リクエスト
  `auditvault` | Oracle Audit Vault and Database Firewallプラグイン
  `bdc` | Oracle Big Data Connectors
  `big_data_sql` | Oracle Big Data SQL
  `disk_encryption` | ディスク上に保存されているデータを自動的に暗号化および復号化します
  `em` | Oracle Enterprise Manager Cloud Controlエージェント
  `kerberos` | Kerberos認証(手動削除のみ)
  `network_encryption` | ネットワーク上を移動中のデータを自動的に暗号化します。Kerberos認証を使用するようにクラスタが設定されている必要があります。
  `sentry` | Apache Sentry認証

  ヒント: 「インストールの前提条件」と「オプション・ソフトウェアの構成の変更」を参照してください。

install node

  指定したノードにソフトウェアをインストールして構成します。

failover node

  重要なサービスを、指定したノードから重要なサービスがないノードに移動します。

update

  クラスタからサービスの構成を変更します。parameterはサービスを識別するキーワードです。表10-2を参照してください。

  表10-2 Mammoth再構成ユーティリティのUPDATEキーワード

  コンポーネント・キーワード | 説明
  --- | ---
  `disk_encryption` | パスワードベースの暗号化に使用するパスワードを変更します。このコマンドは、古いパスワードと新しいパスワードの両方を要求します。 有効なパスワードは、印刷可能な1から64のASCII文字で構成されます。空白文字(スペース、タブ、改行など)、一重または二重引用符、バックスラッシュ(\)を含めることはできません。

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

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

- `makebdaimage`

- `reimagecluster`

- `reimagerack`

### 10.13.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`の工場出荷時の構成または`BdaDeploy.json`のカスタム構成のいずれでもかまいません。構成されたサーバーの`/opt/oracle/bda`にあります。

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

### 10.13.2 reimagecluster

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

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

    reimagecluster [--no-iloms] [from.json [to.json]]

前提条件

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

      $ dcli -C hostname

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

オプション

--no-iloms

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

from.json

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

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

to.json

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

### 10.13.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`または`BdaDeploy.json`)へのフルパスです。

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

to.json

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