| Oracle® Big Data Applianceオーナーズ・ガイド リリース2 (2.0.1) B72460-01 |
|
 前 |
 次 |
この章では、Oracle Big Data Applianceのソフトウェアをインストール、再インストールまたは再構成する方法について説明します。この章の内容は次のとおりです。
|
注意: Mammothではパスワードが保存されないため、各パスワードの入力を求められます。オペレーティング・システムのrootおよびoracleユーザー、Cloudera Managerのadminユーザー、およびMySQL管理者の現在のパスワードを把握していることを確認してください。Oracle Big Data Connectorsを再インストールする場合、Oracle Data IntegratorのMySQLパスワードも必要です。 |
Mammothユーティリティでは、Oracle Big Data Appliance構成ユーティリティによって生成されたファイルを使用して、Oracle Big Data Applianceにソフトウェアをインストールして構成できます。少なくとも、MammothによってCloudera's Distribution including Apache Hadoopをインストールして構成します。これには、すべてのHadoopソフトウェアおよびCloudera Manager (Hadoopクラスタを管理するためのツール)が含まれます。Mammothでは、Oracle NoSQL Databaseと、(ライセンスを持っている場合は)Oracle Big Data Connectorsのすべてのコンポーネントをオプションでインストールして構成できます。
Mammothユーティリティでは、ラック内のすべてのサーバー全体にソフトウェアをインストールする以外に、必要なユーザー・アカウントの作成、適切なサービスの開始、および適切な構成パラメータの設定を行うことができます。この完了時には、完全に機能する高度にチューニングされたHadoopクラスタを実行できます。
Mammothユーティリティは、ラックごとに1回実行する必要があります。
1つのHadoopクラスタを構成する1つのOracle Big Data Applianceラックの場合、「単一ラックまたはプライマリ・ラックへのソフトウェアのインストール」の手順に従います。
各ラックが独立したHadoopクラスタを構成する複数ラックの場合、ラックごとに「単一ラックまたはプライマリ・ラックへのソフトウェアのインストール」の手順に従います。
単一のマルチラックHadoopクラスタを構成する複数ラックの場合:
クラスタのプライマリ・ラックを識別して、「単一ラックまたはプライマリ・ラックへのソフトウェアのインストール」の手順に従います。
クラスタの他のラックの場合、「既存のクラスタへのラックの追加」の手順に従います。
次の手順に従って、単一のOracle Big Data Applianceラックまたは複数ラック・クラスタのプライマリ・ラックにソフトウェアをインストールして構成します。
ソフトウェアをインストールするには、次の手順を実行します。
Oracle Big Data Applianceラックが/opt/oracle/bda/BdaDeploy.jsonに記述されたカスタム・ネットワーク設定に従って構成されていることを確認します。ラックがまだ工場出荷時のデフォルトIPアドレスに構成されている場合、最初に「ネットワークの構成」の手順に従ってネットワーク構成を実行します。
ソフトウェアがまだラックにインストールされていないことを確認します。ソフトウェアがインストールされており、再インストールする場合、手順9でmammoth -pオプションを使用します。
node01の任意のディレクトリ(/tmpなど)にBDAMammoth zipファイルをダウンロードします。ダウンロードの場所については、My Oracle Support情報センターID 1445745.2を参照してください。
rootとしてnode01にログインし、ダウンロードしたzipファイルからすべてのファイルを抽出します。
# unzip p16069298_201_Linux-x86-64.zip
Archive: p16069298_201_Linux-x86-64.zip
inflating: README.txt
creating: BDAMammoth-2.0.1/
inflating: BDAMammoth-2.0.1/bda-configurator-2.0.1.ods
inflating: BDAMammoth-2.0.1/BDAMammoth-2.0.1.run
BDAMammoth-versionディレクトリに移動します。
# cd BDAMammoth-2.0.1
BDAMammoth-version.runからすべてのファイルを抽出します。
# ./BDAMammoth-2.0.1.run
BDAMammothディレクトリに移動します。
# cd /opt/oracle/BDAMammoth
mammoth-rack_name.paramsを現在のディレクトリにコピーします。「構成ファイルについて」を参照してください。
適切なオプションを使用してmammothコマンドを実行します。表9-1を参照してください。次のサンプル・コマンドでは、ラックbda2でステップ1および2が実行されます。
./mammoth -r 1-2 bda2
Mammothユーティリティは、現在の構成を/opt/oracle/bda/install/stateディレクトリに格納します。このディレクトリのファイルは削除しないでください。Mammothユーティリティは、クラスタにラックを追加する場合など、情報を再度使用する必要がある場合にこの情報が存在しないと失敗します。
各マルチラック・クラスタには、プライマリ・ラックとして指定された1つのラックがあります。ラックがプライマリ・ラックであるかどうかは、Oracle Big Data Appliance構成ワークシートに示されており、mammoth-rack_name.paramsファイルに指定されます。マルチラックHadoopクラスタの各ラックには、個別のmammoth-rack_name.paramsファイルがあります。
同じクラスタの追加ラックにソフトウェアをインストールするには、次の手順を実行します。
Hadoopクラスタのプライマリ・ラックにソフトウェアをインストールします。「単一ラックまたはプライマリ・ラックへのソフトウェアのインストール」を参照してください。
すべてのラックで同じソフトウェア・バージョンが実行されていることを確認します。「ソフトウェア・バージョンの違いについて」を参照してください。
単一のHadoopクラスタを構成するすべてのラックがケーブルで接続されていることを確認します。第8章を参照してください。
プライマリ以外のラックのmammoth-rack_name.paramsファイルを、プライマリ・ラックのnode01 (一番下のサーバー)にコピーします。これらをプライマリ以外のラックにコピーしないでください。
rootとしてプライマリ・ラックのnode01に接続し、BDAMammothディレクトリに移動します。
cd /opt/oracle/BDAMammoth
注意: Mammothは常にプライマリ・ラックから起動してください。
プライマリ以外のラックごとに、適切なオプションを使用してmammothコマンドを入力します。「Mammothユーティリティの構文」を参照してください。たとえば、次のコマンドでは、ラックbda4に対するインストールを開始します。
./mammoth -i bda4
マルチラックHadoopクラスタのプライマリ・ラックは、単一のHadoopクラスタの場合と同じように構成されます。これは、NameNode、Hue、Hiveなどの主要サービスを実行します。マルチラックHadoopクラスタの他のラックは、異なる方法で構成されます。これらは、DataNodeおよびTaskTrackerのみを実行します。
Oracle Big Data Connectorsのライセンスを持っている場合、それらはプライマリ以外のラックのすべてのノードにインストールされます(ただし、そこでサービスは実行されません)。Oracle Data Integratorエージェントは、引き続きプライマリ・ラックのnode03で実行されます。設定後にOracle NoSQL Databaseクラスタにノードを追加することはできません。ただし、将来Oracle NoSQL Databaseクラスタにノードを追加できるようになったときに使用するため、追加ラックに論理ボリュームが作成されます。
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を参照してください。
古いバージョンのOracle Big Data Appliance構成ユーティリティを使用して、構成ファイルを生成します。
古いバージョンのMammothユーティリティを使用してソフトウェアをインストールします。
ステップごとに、各サーバーに実行されたアクションとステップが正常に完了したかどうかを示す詳細なログ・ファイルが生成されます。エラーが発生すると、スクリプトは停止します。その後、/opt/oracle/BDAMammoth/bdaconfig/tmpのログ・ファイルを確認できます。ログ・ファイル名の書式は次のとおりです。
STEP-i-yyyymmddhhmmss.log
この書式で、iはステップ番号で、yyyymmddhhmmssはファイルが作成された時刻(年、月、日、時間、分および秒)を示します。
問題を修正したら、全部または一部のステップを再実行できます。ステップ1から3を除き、ステップを省略することや、その順序を無視して実行することはできません。
ソフトウェアをアップグレードする手順は、あるメジャー・リリースから別のメジャー・リリースにアップグレードする場合でも、単にパッチ・セットを適用する場合でも同じです。また、この手順は、Hadoopクラスタが1つのOracle Big Data Applianceラックで構成されていても、複数のラックで構成されていても同じです。
このプロセスによって、ファームウェア、オペレーティング・システム、CDH、JDKおよびOracle Big Data Connectors (事前にインストールされている場合)を含むソフトウェア・スタックのすべてのコンポーネントがアップグレードされます。
ソフトウェアのダウングレードはサポートされません。
|
注意: アップグレード・プロセスでは必要に応じてサービスが自動的に停止および開始されるため、クラスタはmammothコマンドの実行中は使用できません。 |
アップグレードによってクラスタ上のソフトウェアに行われる変更のサマリーを次に示します。
CDH3がCDH4に、Cloudera Manager 3.7がCloudera Manager 4.1.2に置き換えられます。
一部のサービスが別のノードに配置されます。
Cloudera Managerサービスは、node02のかわりにnode03で実行されます。
MySQLデータベースのプライマリとバックアップの位置が入れ替わります。プライマリ・データベースはnode03で実行され、バックアップ・データベースはnode02で実行されます。
クラスタのすべてのノードでマウントされたディレクトリは、node04ではなく、node03からエクスポートされます。
Namenodeの高可用性および自動フェイルオーバーは有効です。
namenodeは2つあり、node01とnode02で実行されます。セカンダリnamenodeはありません。
フェイルオーバー・コントローラは2つあり、node01とnode02で実行されます。
ジャーナル・ノードは3つあり、node01、node02およびnode03で実行されます。
ZooKeeperサービスは、node01、node02およびnode03で稼働するサーバーを使用して構成されます。
Oozieサービスは、node03で稼働するサーバーを使用して構成されます。
マウントされたディレクトリは、NameNodeまたはセカンダリNameNodeデータのバックアップに使用されません。
|
関連項目: バージョン2.0のソフトウェアの詳細は、『Oracle Big Data Applianceソフトウェア・ユーザーズ・ガイド』を参照してください。 |
次の手順に従って、Oracle Big Data Applianceクラスタのソフトウェアをバージョン1.1からバージョン2.0.1にアップグレードします。
ソフトウェアをアップグレードするには、次の手順を実行します。
プライマリ・ラックのnode01の任意のディレクトリ(/tmpなど)にBDAMammoth zipファイルをダウンロードします。ダウンロードの場所については、My Oracle Support情報センターID 1445745.2を参照してください。
Mammothユーティリティのバージョンにアップグレードするため、アプライアンスを2.0.1ソフトウェアにアップグレードするには、Mammoth 2.0.1が必要です。
rootとしてHDFSノード(node01)にログインし、ダウンロードしたzipファイルからすべてのファイルを抽出します。
# unzip p16069298_201_Linux-x86-64.zip
Archive: p16069298_201_Linux-x86-64.zip
inflating: README.txt
creating: BDAMammoth-2.0.1/
inflating: BDAMammoth-2.0.1/bda-configurator-2.0.1.ods
inflating: BDAMammoth-2.0.1/BDAMammoth-2.0.1.run
BDAMammoth-versionディレクトリに移動します。
# cd BDAMammoth-2.0.1
BDAMammoth-version.runからすべてのファイルを抽出します。
# ./BDAMammoth-2.0.1.run
Mammothソフトウェアの新規バージョンは/opt/oracle/BDAMammothにインストールされ、以前のバージョンは/opt/oracle/BDAMammoth/previous-BDAMammothに保存されます。
BDAMammothディレクトリに移動します。
# cd /opt/oracle/BDAMammoth
-pオプションを使用してmammothコマンドを実行します。
./mammoth -p
アップグレードは、複数ステップのプロセスです。様々なメッセージが表示され、アップグレードで実際にクラスタに行われている処理が確認できます。次の処理が自動的に実行されますが、これらはMammothがアップグレード・プロセスのどの段階にあるかの特定に役立ちます。
Oracle Data IntegratorおよびOracle NoSQL Databaseを停止します。
工場出荷時イメージを更新します。
Cloudera Managerを停止します。
Cloudera Managerの新規バージョンをインストールします。
Cloudera Managerを起動します。
Cloudera Managerによって使用されるデータベースをアップグレードします。
すべてのHadoopサービスを停止し、アンインストールします。
Hadoopの新規バージョンをインストールします。
クラスタをCDH3からCDH4にアップグレードし、アップグレードをファイナライズします。
古いCDHサービス(HDFS、MapReduceおよびHue)を削除し、新規サービス(HDFS、MapReduce、Hue、OozieおよびZooKeeper)を作成します。
新規共有ディレクトリをnode03からマウントします。
MySQL Databaseを設定します。
Cloudera Manager用にすべてのノードで新規構成ファイルを設定します。
Cloudera管理サービスをnode02からnode03に移動します。このステップの後、node03のCloudera Manager Webページにアクセスします。
Cloudera Managerを再起動します。
すべてのCDHサービスを起動します。このステップで、高可用性と自動フェイルオーバーを有効化します。
Hiveサービスを再起動します。
すべてのオープン・ソース・パッケージのソース・コードをすべてのノードにコピーします。
オプションのソフトウェア・コンポーネント(Oracle Big Data ConnectorsおよびOracle NoSQL Database)をアップグレードします。
インストールをクリーンアップし、クラスタ・チェックを実行します。
Oracle Big Data Applianceの初期構成中に、オプションのソフトウェア・コンポーネントがインストールされる場合とインストールされない場合があります。Mammoth再構成ユーティリティを使用して、この決定の一部を逆にすることができます。関係のあるサーバー名、ポート、ユーザー名およびパスワードを指定する必要があります。mamoth-reconfig 「add」および「remove」オプションを参照してください。
次の手順では、自動サービス・リクエストに対するサポートの追加方法を示します。
自動サービス・リクエストをサポートするには、次の手順を実行します。
My Oracle Supportアカウントを設定してASRマネージャをインストールします。これは、Oracle Big Data Applianceで自動サービス・リクエストをアクティブ化する前に行います。第5章を参照してください。
プライマリ・ラックの第1 NameNode (node01)にログインし、BDAMammothディレクトリに移動します。
cd /opt/oracle/BDAMammoth
自動サービス・リクエスト監視を有効にしてアセットをアクティブ化します。
# 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 INFO: Checking configuration file /opt/oracle/bda/install/state/mammoth-saved.params... INFO: Using saved configuration file /opt/oracle/bda/install/state/mammoth-saved.params INFO: To use the generated configuration file, remove /opt/oracle/bda/install/state/mammoth-saved.params INFO: Loading configuration file /opt/oracle/bda/install/state/mammoth-saved.params... INFO: Reading component versions from /opt/oracle/BDAMammoth/bdaconfig/COMPONENTS INFO: Creating nodelist files... 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 ... . . .
次の手順では、Oracle Enterprise Manager Cloud Controlに対するサポートの追加方法について示します。
Oracle Enterprise Manager Cloud Controlをサポートするには、次の手順を実行します。
同じネットワーク上のOracle Enterprise Manager Cloud ControlインストールにOracle Big Data Appliance用のシステム監視プラグインをインストールします。『Oracle Enterprise Manager System Monitoring Plug-inインストレーション・ガイドfor Oracle Big Data Appliance』を参照してください。
プライマリ・ラックの第1 NameNode (node01)にログインし、BDAMammothディレクトリに移動します。
cd /opt/oracle/BDAMammoth
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 INFO: Checking configuration file /opt/oracle/bda/install/state/mammoth-saved.params... INFO: Using saved configuration file /opt/oracle/bda/install/state/mammoth-saved.params INFO: To use the generated configuration file, remove /opt/oracle/bda/install/state/mammoth-saved.params INFO: Loading configuration file /opt/oracle/bda/install/state/mammoth-saved.params... INFO: Reading component versions from /opt/oracle/BDAMammoth/bdaconfig/COMPONENTS INFO: Creating nodelist files... 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 ... . . .
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以外の安全な場所に/opt/oracle/BDAMammoth/mammoth-rack_name.paramsファイルを保存します。
適切なバージョンのベース・イメージが含まれるパッチ・ファイルをダウンロードし、それをnode01(一番下のサーバー)にコピーします。ダウンロードの場所については、My Oracle Support情報センターID 1445745.2を参照してください。/tmpなどの任意のディレクトリにファイルをコピーできます。
|
注意: Mammothユーティリティ・パッチ・ファイルを同じMy Oracle Support情報センターからOracle Big Data Appliance外の安全な場所にダウンロードできます。イメージの再適用後、Mammothユーティリティを使用してエンドユーザー・ソフトウェアを再インストールする必要があります。 |
node01に対するSSH接続を確立してrootとしてログインします。
パスワードなしSSHが設定されていることを確認します。
# dcli hostname
192.168.41.37: bda1node01.example.com
192.168.41.38: bda1node02.example.com
192.168.41.39: bda1node03.example.com
.
.
.
このコマンドがエラーなしで実行されると、18のOracle Big Data Applianceサーバーすべてのホスト名が返されます。そうではない場合、「パスワードなしSSHの設定」の手順に従ってください。すべてのサーバーでdcli hostnameコマンドが正常に実行されるまで、作業を継続しないでください。
すべてのOracle Big Data Applianceサーバーでハードウェアの問題をチェックします。
# dcli bdacheckhw | grep -v SUCCESS
ラックにイメージを再適用する前に、ハードウェアのエラーおよび警告を解決します。
すべてのサーバーのルート(/)パーティションが4GB以上空いていることを確認します。
[# 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% /
.
.
.
次のようにzipファイルからすべてのファイルを抽出します。
# unzip p16065021_201_Linux-x86-64.zip
Archive: p16065021_201_Linux-x86-64.zip
inflating: README.txt
creating: BDABaseImage-2.0.1_RELEASE/
inflating: BDABaseImage-2.0.1_RELEASE/BDABaseImage-2.0.1_RELEASE.iso
inflating: BDABaseImage-2.0.1_RELEASE/reimagerack
inflating: BDABaseImage-2.0.1_RELEASE/ubiosconfig
inflating: BDABaseImage-2.0.1_RELEASE/biosconfig
inflating: BDABaseImage-2.0.1_RELEASE/makebdaimage
extracting: BDABaseImage-2.0.1_RELEASE/BDABaseImage-2.0.1_RELEASE.md5sum
次のように、前の手順で作成されたBDABaseImage-version_RELEASEディレクトリに移動します。
# cd BDABaseImage-2.0.1_RELEASE
次のいずれかの手順を完了します。
カスタマ・ネットワーク用に構成されたOracle Big Data Applianceにイメージを再適用して同じカスタマ・ネットワーク設定にするには、次の手順を実行します。
/opt/oracle/bda/BdaDeploy.jsonが存在し、カスタマ・ネットワーク設定が含まれていることを確認します。
./reimagerackコマンドを実行します。
工場出荷時の設定を維持するアプライアンスのイメージに変更するには、次のようにします。
/opt/oracle/bda/bdaShip.jsonが存在することを確認します。
/opt/oracle/bda/BdaDeploy.jsonが存在しないことを確認します。
./reimagerackコマンドを実行します。
カスタム・ネットワーク設定を使用して構成されたラックで工場出荷時のネットワーク設定をリストアするには、次のようにします。
/opt/oracle/bda/BdaDeploy.jsonが存在し、カスタマ・ネットワーク設定が含まれていることを確認します。
Oracle Big Data Appliance以外の安全な場所に/opt/oracle/bda/BdaDeploy.jsonをコピーします。
/opt/oracle/bda/BdaShip.jsonが存在することを確認します。
ネットワークからラックの接続を切断します。
ラックのイメージを変更します。
./reimagerack deploy ship
reimagerackユーティリティは、ISOイメージを作成してそれをラックの各サーバーの内部USBドライブにコピーし、各サーバーを再起動してインストールを初期化します。すべてのサーバーでベース・イメージを再インストールするには、約1時間かかります。
rootのパスワードなしSSHを設定します。
# setup-root-ssh
「setup-root-ssh」を参照してください。
dcliを使用してクラスタ内のすべてのサーバーを手動で再起動し、/rootディレクトリにBDA_IMAGING_SUCCEEDEDおよびBDA_REBOOT_SUCCEEDEDファイルが存在することを確認します。
]# dcli ls /root/BDA_*
192.168.42.37: /root/BDA_IMAGING_SUCCEEDED
192.168.42.37: /root/BDA_REBOOT_SUCCEEDED
192.168.42.38: /root/BDA_IMAGING_SUCCEEDED
192.168.42.38: /root/BDA_REBOOT_SUCCEEDED
192.168.42.39: /root/BDA_IMAGING_SUCCEEDED
192.168.42.39: /root/BDA_REBOOT_SUCCEEDED
.
.
.
Mammothユーティリティを実行します。「単一ラックまたはプライマリ・ラックへのソフトウェアのインストール」を参照してください。
Mammothユーティリティを使用するには、rootとして第1サーバーにログインし、/opt/oracle/BDAMammothディレクトリに移動する必要があります。構文は次のとおりです。
./mammoth option [rack_name]
このコマンドで、rack_nameはOracle Big Data Applianceラックの名前です。ラック名は、構成ファイル名(mammoth-rack_name.params)に含まれる名前とまったく同じように最初のコマンドに入力する必要があります。その後、rack_nameはデフォルトで前のmammothコマンドで指定されたラックになります。
あるラックのインストールを完了してから、別のラックのインストールを開始する必要があります。
例9-1 Mammothユーティリティの構文例
次のコマンドでは、Mammothユーティリティのヘルプを表示します。
./mammoth -h
次のコマンドでは、ラックbda3に対して完全なインストールを実行します。
./mammoth -i bda3
次のコマンドでは、設定中のラックに対してステップ2から6を実行します。
./mammoth -r 2-6
次に、ソフトウェアのインストール時にMammothユーティリティおよびMammoth再構成ユーティリティが実行するステップについて説明します。
このステップでは、次の複数のタスクが実行されます。
構成ファイルを検証し、パスワードを要求します。
パスワードを入力せずに管理ネットワークのすべてのアドレスに接続できるように、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ユーティリティが成功したこと。
このステップでは、すべてのノードでPuppetエージェントを構成して起動し、Mammothユーティリティが実行されているノードでPuppetマスターを構成し、エージェントが証明書を発行するのを待機してその署名を自動化します。このステップが完了すると、Puppetはソフトウェアをデプロイできます。
Puppetは、Hadoopクラスタを管理するために一般的に使用される分散構成管理ツールです。Puppetマスターは、親のサービスであり、Puppetリポジトリを管理します。Puppetエージェントは、各Hadoopノードで動作します。
/etc/puppet/puppet.confという名前のファイルがすべてのサーバーに存在し、Puppetマスターの場所を指定します。
Puppetは2つのモードで動作します。
定期的プル・モード: Puppetエージェントは定期的にPuppetマスターと通信し、更新の有無を確認します。
キック・モード: Puppetマスターは、構成の更新が使用できるというアラートをPuppetエージェントに通知し、エージェントは更新の有無を確認します。Puppetは、Mammothユーティリティのインストール中はキック・モードで動作します。
どちらのモードでも、Puppetマスターは、エージェントを信頼する必要があります。この信頼を確立するため、エージェントは、システム管理プロセスによる署名が行われるPuppetマスター・ノードに証明書を送信します。このトランザクションが完了すると、Puppetマスターは、エージェントに新しい構成を送信します。
後続のステップでは、「インストール中にエラーが発生した場合の対処方法」の説明に従って、各サーバーのPuppetログ・ファイルを確認できます。
最新のOracle Big Data Applianceイメージおよびシステム・パラメータ設定をインストールします。
ライセンス契約の要件に応じて、サード・パーティ・ライセンスをすべてのサーバーの/opt/oss/src/OSSLicenses.pdfにコピーします。
ランセンス契約の要件に応じて、サード・パーティ・ソフトウェアのソース・コードをすべてのサーバーの/opt/oss/src/にコピーします。
物理ディスクがOracle NoSQL Databaseに割り当てられている場合、論理ボリュームを作成します。このステップは、構成中にOracle NoSQL Databaseに割り当てられたディスク領域の容量に応じて変化します。
0TB: このステップでは何も実行されません。
54TB: ディスク領域は、各ノードの1つのディスクを使用してクラスタ全体に割り当てられます。/u12にマウントされたディスクが論理ボリューム用として使用されます。
108TB: ディスク領域は、各ノードの2つのディスクを使用してクラスタ全体に割り当てられます。/u11および/u12にマウントされたディスクが論理ボリューム用として使用されます。
論理ボリュームは、/lv1にマウントされ、デバイス/dev/lvg1/lv1に対応します。
このステップの完了後、/etc/fstabにあるLinuxファイル・システム表には、/u12 (または/u11および/u12)のかわりに論理ディスクが表示されます。
hdfsおよびmapredユーザーと、hadoopグループを作成します。また、oracleユーザーと、dbaおよびoinstallグループも作成します。
後のステップでインストールされる様々なパッケージによっても、インストール中にユーザーおよびグループが作成されます。
|
関連項目: ユーザーおよびグループの詳細は、『Oracle Big Data Applianceソフトウェア・ユーザーズ・ガイド』を参照してください。 |
NameNodeデータが設定されているディスクまたはノード全体で障害が発生した場合にこの重要な情報の損失を防ぐため、このデータを複数の場所にコピーします。
MySQL Databaseをインストールして構成します。このステップでは、Cloudera Managerで使用するためにnode03にプライマリ・データベースと複数のデータベースが作成されます。また、node02のバックアップ・データベースに対するプライマリ・データベースのレプリケーションも設定されます。
Cloudera's Distribution including Apache Hadoop (CDH)およびCloudera Managerのすべてのパッケージをインストールします。その後、node03でCloudera Managerサーバーを起動し、クラスタを構成します。
すべてのノードのエージェントを起動し、すべてのCDHサービスを開始します。このステップの後、Hadoopインストール環境が完全に機能します。
Cloudera Managerは、node03のポート7180で実行されます。これは次のようにブラウザで開くことができます。
http://bda1node03.example.com:7180
この例では、bda1node02がnode02の名前で、example.comがドメインです。デフォルトのユーザー名とパスワードは、adminです(これはステップ17で変更されます)。
node03でHiveサービスを開始し、Hadoopクライアント構成をすべてのノードの/etc/hadoop/confにコピーします。
Oracle NoSQL Database Community EditionおよびOracle Big Data Connectorsのサーバー側コンポーネントをインストールします(これらのオプションがOracle Big Data Appliance構成ワークシートで選択されている場合)。Oracle NoSQL Databaseにはディスク領域(54または108TB)を割り当てる必要があり、Oracle Big Data Connectorsは個別にライセンスされている必要があります。
Oracle Enterprise Managerエージェントをインストールして構成します。
自動サービス・リクエスト(ASR)をインストールして構成します。
このステップでは、次のことが実行されます。
必要なソフトウェア・パッケージをインストールします。
トラップ宛先を構成します。
監視デーモンを起動します。
ASRマネージャからアセットをアクティブ化するには、「ASRアセットの確認」を参照してください。
次のことが実行されます。
すべてのノードのrootパスワードを変更します(オプション)。
Cloudera Managerパスワードを変更します(インストール・テンプレートに指定されている場合)。
インストール中に作成された一時ファイルを削除します。
すべてのノードから/opt/oracle/bda/install/logのサブディレクトリにログ・ファイルをコピーします。
クラスタ検証チェック(TeraSortを含む)を実行して、すべてが適切に動作することを確認します。また、インストール・サマリーも生成されます。すべてのログは、node01の/opt/oracle/bda/install/log以下のサブディレクトリに格納されます。
ステップ1で設定したrootのパスワードなしSSHを削除します。
Mammoth再構成ユーティリティを使用するには、rootとして第1サーバーにログインし、/opt/oracle/BDAMammothディレクトリに移動する必要があります。構文は次のとおりです。
./mammoth-reconfig option parameter
オプション
クラスタにサービスを追加します。parameterはサービスを識別するキーワードです。
asr: Oracle Big Data Applianceで自動サービス・リクエスト監視を有効にし、ASRマネージャでアセットをアクティブ化します。インストール・プロセスによって、ASRマネージャのホスト名、ポート番号、ユーザーおよびパスワードの入力を求められます。自動サービス・リクエストの詳細は、第5章を参照してください。
em: Oracle Big Data Appliance用Oracle Enterprise Managerシステム監視プラグインに対するサポートをインストールします。インストール・プロセスによって、Oracle Management System (OMS)ホスト名とポート番号、Enterprise Managerスーパー管理ユーザーとパスワード、Enterprise Managerエージェント登録パスワードの入力を求められます。
次の例では、クラスタ内のすべてのサーバーに自動サービス・リクエスト・サポートを追加します。
# cd /opt/oracle/BDAMammoth # ./mammoth-reconfig add asr
必要な情報の詳細は「ソフトウェア構成」を、サンプル出力は「オプション・ソフトウェアの構成の変更」を参照してください。
クラスタからサービスを削除します。parameterはサービスを識別するキーワードです。
em: Oracle Enterprise Managerシステム監視プラグインに対するサポートを削除します。Enterprise Managerスーパー管理ユーザーのパスワードを指定する必要があります。
次の例では、クラスタ内のすべてのサーバーからOracle Enterprise Managerサポートを削除します。
# cd /opt/oracle/BDAMammoth # ./mammoth-reconfig remove em
