| Oracle® Big Data Applianceオーナーズ・ガイド リリース2 (2.5) E53258-01 |
|
 前 |
 次 |
この章では、Oracle Big Data Applianceのソフトウェアをインストール、再インストールおよび再構成する方法について説明します。この章の内容は次のとおりです。
|
注意: Oracle Big Data Appliance構成生成ユーティリティで必要なパスワードを入力しなかった場合、ソフトウェアのインストール時に入力するように要求されます。オペレーティング・システムのrootおよびoracleユーザー、Cloudera Managerのadminユーザー、およびMySQL管理者の現在のパスワードを把握していることを確認してください。Oracle Big Data Connectorsをインストールまたは再インストールする場合、Oracle Data IntegratorのMySQLパスワードも必要です。 |
Mammothは、Oracle Big Data Applianceソフトウェアをインストールおよび構成するためのコマンドライン・ユーティリティです。Mammothを使用すると、次のことを実行できます。
複数のラックにクラスタを作成できます。
Oracle Big Data Applianceのラックに複数のクラスタを作成できます。
クラスタを新しいサーバーに拡張できます。
新しいソフトウェアでクラスタを更新できます。
初期のソフトウェアのインストール中またはインストール後に自動サービス・リクエストをデプロイできます。
初期のソフトウェアのインストール中またはインストール後にOracle Big Data Appliance用のOracle Enterprise Managerシステム監視プラグインをデプロイできます。
Oracle Audit Vault、自動サービス・リクエストおよびOracle Enterprise Managerオプションは、Oracle Big Data Applianceと同じネットワークのリモート・サーバーにソフトウェアが必要です。Mammothを実行する前にそれらのインストールが完了している必要があり、そうでない場合は失敗します。
同様に、キー配布センター(KDC)がリモート・サーバーにインストールされている場合には、Kerberosに対してもいくつかの手順を完了する必要があります。Oracle Big Data ApplianceにKDCをインストールする場合、事前に行う手順はありません。
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アップロード・ポートとコンソール・ポートの両方が開いている。
kadminから次のコマンドを実行し、cloudera-scm/adminをユーザーとしてKDCデータベースに追加します。
addprinc -randkey cloudera-scm/admin@<REALM NAME>
cloudera-scm/adminに、Kerberosデータベースに対するすべての権限を付与します。データベースからプリンシパルを追加、修正、削除、リストできる必要があります。
kadminから次のコマンドを実行して、cmf.keytabファイルを作成します。
xst -k cmf.keytab cloudera-scm/admin@<REALM NAME>
cmf.keytabを/opt/oracle/BDAMammothに移動します。
OozieとHueをサポートするには、リモートKDCが更新可能なチケットをサポートしていることを確認してください。サポートしていない場合には、次の手順を実行します。
kdc.confを開き、max_lifeとmax_renewable_lifeの値を設定します。max_lifeパラメータはチケットが有効な期間を定義し、max_renewable_lifeパラメータはユーザーがチケットを更新できる期間を定義します。
krbtgtプリンシパルのmaxrenewlifeを設定します。次のkadminコマンドを使用して、durationを所定の期間で置き換え、REALM NAMEをレルムの名前で置き換えます。
modprinc -maxrenewlife duration krbtgt/REALM NAME
Kerberosを構成するとき、KDCが更新可能なチケットをサポートしない場合には、OozieとHueが正常に動作しないことがあります。
Mammothバンドルには、インストール・ファイルとベース・イメージが含まれます。ソフトウェアをインストールする前に、「構成ファイルの生成」の説明に従い、Oracle Big Data Appliance構成生成ユーティリティを使用して構成ファイルを生成する必要があります。
ラック・サイズや、CDHまたはOracle NoSQL Databaseクラスタを作成しているか、または既存のクラスタをアップグレードしているかにかかわらず、この章で説明されているすべての手順に同じバンドルを使用します。
Mammothバンドルをダウンロードするには、次の手順を実行します。
My Oracle Supportにログインして、ナレッジ・ベースで情報センターID 1445745.2を検索します。
適切なリリース番号とパッチを探します。
BDAMammoth ZIPファイルをクラスタの第1ノードの任意のディレクトリ(/tmpなど)にダウンロードします。ラックの構成に応じて、このノードはラックの下から数えて1番目、7番目または13番目のサーバーになる場合があります。マルチラック・クラスタの場合、このサーバーはプライマリ・ラックにあります。
パッチは、次の2つのファイルで構成されます。
クラスタの第1ノードにrootとしてログインします。
ダウンロードしたzipファイルからすべてのファイルを解凍します。次に例を示します。
$ unzip p12345678_250_Linux-x86-64_1of2.zip Archive: p12345678_250_Linux-x86-64_1of2.zip inflating: README.txt creating: BDAMammoth-ol6-2.5.0/ inflating: BDAMammoth-ol6-2.5.0/BDAMammoth-ol6-2.5.0.run $ unzip p12345678_250_Linux-x86-64_2of2.zip Archive: p12345678_250_Linux-x86-64_2of2.zip creating: BDABaseImage-ol6-2.5.0_RELEASE/ inflating: BDABaseImage-ol6-2.5.0_RELEASE/biosconfig inflating: BDABaseImage-ol6-2.5.0_RELEASE/reimagecluster inflating: BDABaseImage-ol6-2.5.0_RELEASE/reimagerack inflating: BDABaseImage-ol6-2.5.0_RELEASE/makebdaimage inflating: BDABaseImage-ol6-2.5.0_RELEASE/BDABaseImage-ol6-2.5.0_RELEASE.iso inflating: BDABaseImage-ol6-2.5.0_RELEASE/README.txt extracting: BDABaseImage-ol6-2.5.0_RELEASE/BDABaseImage-ol6-2.5.0_RELEASE.md5sum inflating: BDABaseImage-ol6-2.5.0_RELEASE/ubiosconfig
BDAMammoth-versionディレクトリに移動します。
# cd BDAMammoth-ol6-2.5.0
BDAMammoth-version.runからすべてのファイルを抽出します。
# ./BDAMammoth-ol6-2.5.0.run
Big Data Appliance Mammoth v2.5.0 Self-extraction
Checking for and testing BDA Base Image in /tmp
BDABaseImage-2.5.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に保存されます。
実行中のインストール・タイプに固有の手順に従います。
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ラックの場合は、「単一ラックまたはプライマリ・ラックへのソフトウェアのインストール」の手順に従います。
各ラックが独立したクラスタを構成する複数ラックの場合は、ラックごとに「単一ラックまたはプライマリ・ラックへのソフトウェアのインストール」の手順を実行します。
単一のマルチラック・クラスタを構成する複数ラックの場合は、次のようになります。
クラスタのプライマリ・ラックを識別して、「単一ラックまたはプライマリ・ラックへのソフトウェアのインストール」の手順に従います。
クラスタのその他のラックの場合は、「クラスタへのサーバーの追加」の手順に従います。
次の手順に従って、単一のOracle Big Data Applianceラックまたは複数ラック・クラスタのプライマリ・ラックにソフトウェアをインストールして構成します。
単一ラックまたはプライマリ・ラックにソフトウェアをインストールするには、次の手順を実行します。
Oracle Big Data Applianceラックが/opt/oracle/bda/BdaDeploy.jsonに記述されたカスタム・ネットワーク設定に従って構成されていることを確認します。ラックがまだ工場出荷時のデフォルトIPアドレスに構成されている場合、最初に「ネットワークの構成」の手順に従ってネットワーク構成を実行します。
ソフトウェアがまだラックにインストールされていないことを確認します。ソフトウェアがインストールされており、アップグレードする場合は、手順6でmammoth -pオプションを使用します。
「Mammothソフトウェア・デプロイメント・バンドルのダウンロード」の説明に従って、Mammothバンドルをダウンロードして解凍します。クラスタの第1サーバーにrootとしてログインしている必要があります。
BDAMammothディレクトリに移動します。
# cd /opt/oracle/BDAMammoth
mammoth-rack_name.paramsを現在のディレクトリにコピーします。「構成ファイルについて」を参照してください。
適切なオプションを使用してmammothコマンドを実行します。「Mammothソフトウェア・インストールおよび構成ユーティリティ」を参照してください。このサンプル・コマンドはすべての手順を実行します。
./mammoth -i rack_name
自動サービス・リクエストのサポートをインストールした場合は、「自動サービス・リクエストのインストールの確認」の手順を実行します。
サーバー上の別のCDHクラスタを構成するには、次の手順を実行します。
|
注意: Mammothは、現在の構成を/opt/oracle/bda/install/stateディレクトリに格納します。このディレクトリのファイルは削除しないでください。クラスタにラックを追加するなど、Mammothをもう一度使用する必要がある場合に、この情報が不足していると実行が失敗します。 |
自動サービス・リクエストのインストールの確認
My Oracle Support (http://support.oracle.com)にログインします。
ドキュメントID 1450112.1のASREXACHECKによるASR Exadataの構成チェックに関するドキュメントを検索し、asrexacheckスクリプトをダウンロードします。
本来、これはOracle Exadata Database Machineに対して実施するチェックですが、現在はOracle Big Data Applianceでもサポートされています。
asrexacheckをOracle Big Data Applianceクラスタのサーバーにコピーします。
rootとしてそのサーバーにログインします。
asrexacheckをクラスタ内のすべてのサーバーにコピーします。
# dcli -C -f asrexacheck -d /opt/oracle.SupportTools
dcliの詳細は、第13章を参照してください。
ファイルのアクセス権限を変更します。
# dcli -C chmod 755 /opt/oracle.SupportTools/asrexacheck
スクリプトを実行します。
# dcli -C /opt/oracle.SupportTools/asrexacheck
Oracle Supportのリクエスト(SR)を保存してASRインストールを検証します。次の選択項目に注意してください。
「What is the Problem?」の「Hardware」タブをクリックします。
「Products Grouped By」で、「Hardware License」を選択します。
「Problem Type」で、「My - Auto Service Request (ASR) Installation and Configuration Issues」を選択します。
asrexacheckの出力を含みます。
ソフトウェア・インストール手順のステップ8を続行します。
3つのサーバーのグループに分けられた既存のクラスタにサーバーを追加できます。フル・ラックは、少数のサーバーを追加する場合と同じように追加します。ただし、Oracle Big Data Appliance構成生成ユーティリティで構成ファイルは生成されません。かわりに、Mammothを使用して構成ファイルを生成し、それを使用してサーバーを構成します。
クラスタの追加サーバーにソフトウェアをインストールするには、次の手順を実行します。
すべてのサーバーで同じソフトウェア・バージョンが実行されていることを確認します。「ソフトウェア・バージョンの違いについて」を参照してください。
単一のHadoopクラスタを構成するすべてのラックがケーブルで接続されていることを確認します。第9章を参照してください。
rootとしてプライマリ・ラックのnode01に接続し、BDAMammothディレクトリに移動します。
cd /opt/oracle/BDAMammoth
注意: Mammothは常にプライマリ・ラックから起動してください。
サーバー・グループのパラメータ・ファイルを生成します。次の例では、ノード13から数えて6つのサーバーを追加します。
./mammoth -e node13 6
「Mammothソフトウェア・インストールおよび構成ユーティリティ」で-eオプションを参照してください。
拡張番号の入力を求められた場合は、1から5の整数を入力します。
ソフトウェアをインストールします。次の例では、拡張番号が1のbda3のサーバーでソフトウェアのインストールを開始します。
./mammoth -i bda3 1
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以上をインストールする必要があります。
ステップごとに、各サーバーに実行されたアクションとステップが正常に完了したかどうかを示す詳細なログ・ファイルが生成されます。エラーが発生すると、スクリプトは停止します。その後、/opt/oracle/BDAMammoth/bdaconfig/tmpのログ・ファイルを確認できます。ログ・ファイル名の書式は次のとおりです。
STEP-i-yyyymmddhhmmss.log
この書式で、iはステップ番号で、yyyymmddhhmmssはファイルが作成された時刻(年、月、日、時間、分および秒)を示します。
問題を修正したら、全部または一部のステップを再実行できます。ステップをスキップしたり、順序を変更してステップを実行することはできません。
ソフトウェアをアップグレードする手順は、あるメジャー・リリースから別のメジャー・リリースにアップグレードする場合でも、単にパッチ・セットを適用する場合でも同じです。また、この手順は、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つのバージョンのソフトウェア・バンドルを使用できます。
ソフトウェアのダウングレードはサポートされません。
|
注意: アップグレード・プロセスでは必要に応じてサービスが自動的に停止および開始されるため、クラスタはmammothコマンドの実行中は使用できません。 |
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を使用してソフトウェアをインストールできます。
次の手順に従って、Oracle Big Data Applianceクラスタのソフトウェアをバージョン2.0以上からバージョン2.5にアップグレードします。
以前のバージョンをまず2.0にアップグレードする必要があります。
Mammothユーティリティによってパスワードが求められた場合、クラスタで現在有効な次のパスワードが必要です。
oracle
root
Cloudera Manager admin
MySQL Database admin
Oracle Data IntegratorのMySQL Database (Oracle Data Integratorエージェントがインストールされている場合)
このアップグレードで、OozieデータはApache DerbyからMySQL Databaseに移行されます。Oozieジョブが実行中の場合、アップグレードはエラーで停止します。Oozieが使用中であることがわかっている場合、または先にアップグレードを開始してアップグレードが失敗した場合には、アップグレード前に「Oozieバックエンドの移行」の手順に従ってください。
|
注意: Oracle Big Data Appliance2.2以上のバージョンは、CDHクラスタのOracle NoSQL Databaseをサポートしていません。アップグレードすると、Oracle NoSQL Databaseがデータを含めて完全に削除されます。Oracle NoSQL Database用の別のクラスタを作成する必要があります。 |
Oracle Big Data Applianceソフトウェアをバージョン2.5にアップグレードするには、次の手順を実行します。
クラスタでOracle NoSQL Databaseが現在サポートされている場合、Oracle NoSQL Databaseのバックアップ・ファイルを作成する標準の手順を実行します。
「Mammothソフトウェア・デプロイメント・バンドルのダウンロード」の説明に従って、Mammothバンドルをダウンロードして解凍します。クラスタの第1サーバーにrootとしてログインしている必要があります。
BDAMammothディレクトリに移動します。
# cd /opt/oracle/BDAMammoth
すべてのデータをバックアップした後、Oracle NoSQL Databaseを削除します。
# ./mammoth-reconfig remove nosqldb
-pオプションを使用してmammothコマンドを実行します。
# ./mammoth -p
Oozieに関するエラーでアップグレードが失敗した場合には、「Oozieバックエンドの移行」の手順に従ってください。
Oracle Enterprise Manager Cloud Controlを使用してOracle Big Data Applianceを監視している場合、再検出を実行してソフトウェアの変更を特定します。
OozieデータをDerbyからMySQL Databaseに移行するには、次の手順を実行します。
Cloudera Managerを開き、実行中のOozieジョブがあるかどうかを確認して、一時停止します。
データを移行します。
# mammoth-reconfig migrate oozie
エラーがあれば手動で解決します。
ステップ5からアップグレードを続行します。
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 ... . . .
ディスク暗号化は、次の手順で構成します。
ディスク暗号化をサポートするには、次の手順を実行します。
プライマリ・ラックの第1 NameNode (node01)にログインし、BDAMammothディレクトリに移動します。
cd /opt/oracle/BDAMammoth
現在のクラスタでTPMまたはパスワード暗号化を構成します。この例では、パスワード暗号化を構成します。
# mammoth-reconfig enable disk-encryption Use TPM (motherboard chip) Disk Encryption (y/n) : n Enter password to use for disk encryption Enter password: password Enter password again: password
暗号化方法の詳細は、「ディスク暗号化」を参照してください。
パスワードを変更するには、mammoth-reconfig updateコマンドを使用します。
Kerberos認証をサポートするには、次の手順を実行します。
「インストールの前提条件」にリストされているKerberosの前提条件が完全に満たされていることを確認します。
プライマリ・ラックの第1 NameNode (node01)にログインし、BDAMammothディレクトリに移動します。
cd /opt/oracle/BDAMammoth
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: 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... 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. 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# . . .
Oracle Big Data Applianceには、「Oracle Big Data Appliance管理ソフトウェア」の説明どおり、オペレーティング・システムおよび様々なユーティリティが工場出荷時にインストールされています。たとえば、Oracle Big Data Applianceを元の状態に戻す場合や、Mammothを使用してOracle Big Data Applianceソフトウェアをインストールする前にベース・イメージを最新のバージョンにアップグレードする場合、このベース・イメージを再インストールする必要があります。
ラックのすべてまたは一部のイメージを変更できます。ただし、クラスタ内のすべてのサーバーは同じイメージである必要があります。適切な手順を実行します。
この手順を実行して単一のサーバーのイメージを変更します。たとえば、次のように障害サーバーを交換する場合を見てみます。
|
注意: サーバーのイメージを変更すると、すべてのファイルとデータが消去されます。 |
単一のサーバーにベース・イメージを再インストールするには、次の手順を実行します。
My Oracle SupportまたはOracle Automated Release Updates (ARU)から最新のベース・イメージ・パッチをダウンロードして、イメージを変更するサーバーにコピーします。Mammothバンドルと一緒にダウンロードしたベース・イメージを使用するか、個別のベース・イメージ・パッチをダウンロードできます。
「Mammothソフトウェア・デプロイメント・バンドルのダウンロード」を参照してください。同じ基本手順でMy Oracle Supportからベース・イメージ・パッチをダウンロードできます。
現在のカスタマ設定のイメージをサーバーに再適用するには、意図したネットワーク構成が/opt/oracle/bda/BdaDeploy.jsonに反映されていることを確認します。反映されていない場合は、Oracle Big Data Appliance構成生成ユーティリティを使用して新しいファイルを生成します。「構成ファイルの生成」を参照してください。
パーティションに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
.
.
.
ダウンロードしたベース・イメージのZIPファイルを解凍します(2/2)。次に例を示します。
$ unzip p12345678_250_Linux-x86-64_2of2.zip
Archive: p12345678_250_Linux-x86-64_2of2.zip
creating: BDABaseImage-ol6-2.5.0_RELEASE/
inflating: BDABaseImage-ol6-2.5.0_RELEASE/biosconfig
inflating: BDABaseImage-ol6-2.5.0_RELEASE/reimagecluster
inflating: BDABaseImage-ol6-2.5.0_RELEASE/reimagerack
inflating: BDABaseImage-ol6-2.5.0_RELEASE/makebdaimage
inflating: BDABaseImage-ol6-2.5.0_RELEASE/BDABaseImage-ol6-2.5.0_RELEASE.iso
inflating: BDABaseImage-ol6-2.5.0_RELEASE/README.txt
extracting: BDABaseImage-ol6-2.5.0_RELEASE/BDABaseImage-ol6-2.5.0_RELEASE.md5sum
inflating: BDABaseImage-ol6-2.5.0_RELEASE/ubiosconfig
前の手順で作成したサブディレクトリに移動します。
$ cd BDABaseImage-ol6-2.5.0_RELEASE
makebdaimageコマンドを使用してサーバーのイメージを変更します。次の例では、内部USBを含めたサーバー4のイメージを、2.5.0ベース・イメージからBdaDeploy.jsonのカスタム設定に変更しています。イメージを変更するサーバー(この例では、サーバー4)にログインしている必要があります。
./makebdaimage -usbint BDABaseImage-ol6-2.5.0_RELEASE.iso /opt/oracle/bda/BdaDeploy.json 4
コマンドの完全な構文は、makebdaimageを参照してください。
makebdaimageコマンドがエラーなしに成功した場合には、サーバーを再起動します。
|
注意: ラック全体のイメージを変更すると、ラック上のすべてのクラスタ、ファイルおよびデータが消去されます。 |
ラックのすべてのサーバーにベース・イメージを再インストールするには、次の手順を実行します。
Oracle Big Data Applianceソフトウェアを以前にラックにインストールしている場合、Oracle Big Data Appliance以外の安全な場所に/opt/oracle/BDAMammoth/mammoth-rack_name.paramsファイルを保存します。
My Oracle SupportまたはOracle Automated Release Updates (ARU)から最新のベース・イメージ・パッチをダウンロードして、イメージを変更するラックの第1サーバー(最下部)にコピーします。Mammothバンドルと一緒にダウンロードしたベース・イメージを使用するか、個別のベース・イメージ・パッチをダウンロードできます。
「Mammothソフトウェア・デプロイメント・バンドルのダウンロード」を参照してください。同じ基本手順でMy Oracle Supportからベース・イメージ・パッチをダウンロードできます。
第1サーバーのSSH接続を確立して、rootとしてログインします。
既存のカスタマ・ネットワーク設定のイメージを再適用するには、意図したネットワーク構成が/opt/oracle/bda/BdaDeploy.jsonに反映されていることを確認します。反映されていない場合は、Oracle Big Data Appliance構成生成ユーティリティを使用して新しいファイルを生成します。「構成ファイルの生成」を参照してください。
パスワードなし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コマンドが正常に実行されるまで、作業を継続しないでください。
すべての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ファイルを解凍します(2/2)。次に例を示します。
$ unzip p12345678_250_Linux-x86-64_2of2.zip
Archive: p12345678_250_Linux-x86-64_2of2.zip
creating: BDABaseImage-ol6-2.5.0_RELEASE/
inflating: BDABaseImage-ol6-2.5.0_RELEASE/biosconfig
inflating: BDABaseImage-ol6-2.5.0_RELEASE/reimagecluster
inflating: BDABaseImage-ol6-2.5.0_RELEASE/reimagerack
inflating: BDABaseImage-ol6-2.5.0_RELEASE/makebdaimage
inflating: BDABaseImage-ol6-2.5.0_RELEASE/BDABaseImage-ol6-2.5.0_RELEASE.iso
inflating: BDABaseImage-ol6-2.5.0_RELEASE/README.txt
extracting: BDABaseImage-ol6-2.5.0_RELEASE/BDABaseImage-ol6-2.5.0_RELEASE.md5sum
inflating: BDABaseImage-ol6-2.5.0_RELEASE/ubiosconfig
前の手順で作成したサブディレクトリに移動します。
$ cd BDABaseImage-ol6-2.5.0_RELEASE
次のいずれかの手順を完了します。
カスタマ・ネットワーク用に構成されたOracle Big Data Applianceにイメージを再適用して同じカスタマ・ネットワーク設定にするには、./reimagerackコマンドを実行します。
工場出荷時の設定を維持するアプライアンスのイメージに変更するには、次のようにします。
/opt/oracle/bda/BdaDeploy.jsonが存在しないことを確認します。
./reimagerackコマンドを実行します。
カスタム・ネットワーク設定を使用して構成されたラックで工場出荷時のネットワーク設定をリストアするには、次のようにします。
Oracle Big Data Appliance以外の安全な場所に/opt/oracle/bda/BdaDeploy.jsonをコピーします。
/opt/oracle/bda/BdaShip.jsonが存在することを確認します。
ラックのイメージを変更します。
./reimagerack deploy ship
コマンドの完全な構文は、reimagerackを参照してください。
Mammothを実行します。「単一ラックまたはプライマリ・ラックへのソフトウェアのインストール」を参照してください。
この手順を実行して、Mammothユーティリティがクラスタとしてデプロイしたサーバー・グループのイメージを変更します。既存のネットワーク設定は、イメージの変更後に自動的に再適用されます。
|
注意: クラスタのイメージを変更すると、クラスタ上のすべてのファイルとデータが消去されます。イメージの変更は、ソフトウェアのアップグレードには必要ありません。 |
クラスタ内のすべてのサーバーのベース・イメージを再インストールするには、次の手順を実行します。
Oracle Big Data Appliance以外の安全な場所に/opt/oracle/BDAMammoth/mammoth-rack_name.paramsファイルを保存します。
My Oracle SupportまたはOracle Automated Release Updates (ARU)から最新のベース・イメージ・パッチをダウンロードして、イメージを変更するクラスタの第1サーバーにコピーします。ファイルは任意のディレクトリにコピーできます(/tmpなど)。ダウンロードの場所については、My Oracle Support情報センターID 1445745.2を参照してください。
Mammothバンドルと一緒にダウンロードしたベース・イメージを使用するか、個別のベース・イメージ・パッチをダウンロードできます。
ラック内のクラスタの構成に応じて、第1サーバーは下から数えて1番目、7番目、10番目または13番目になる場合があります。
第1サーバーのSSH接続を確立して、rootとしてログインします。
意図したネットワーク構成が/opt/oracle/bda/BdaDeploy.jsonに反映されていることを確認します。反映されていない場合は、Oracle Big Data Appliance構成生成ユーティリティを使用して新しいファイルを生成します。「構成ファイルの生成」を参照してください。
パスワードなし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コマンドが正常に実行されるまで、作業を継続しないでください。
すべてのOracle Big Data Applianceサーバーでハードウェアの問題をチェックします。
# dcli -C bdacheckhw | grep -v SUCCESS
ラックにイメージを再適用する前に、ハードウェアのエラーおよび警告を解決します。
すべてのサーバーのルート(/)パーティションが4GB以上空いていることを確認します。
# 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% /
.
.
.
ダウンロードしたベース・イメージのZIPファイルを解凍します(2/2)。次に例を示します。
$ unzip p12345678_250_Linux-x86-64_2of2.zip
Archive: p12345678_250_Linux-x86-64_2of2.zip
creating: BDABaseImage-ol6-2.5.0_RELEASE/
inflating: BDABaseImage-ol6-2.5.0_RELEASE/biosconfig
inflating: BDABaseImage-ol6-2.5.0_RELEASE/reimagecluster
inflating: BDABaseImage-ol6-2.5.0_RELEASE/reimagerack
inflating: BDABaseImage-ol6-2.5.0_RELEASE/makebdaimage
inflating: BDABaseImage-ol6-2.5.0_RELEASE/BDABaseImage-ol6-2.5.0_RELEASE.iso
inflating: BDABaseImage-ol6-2.5.0_RELEASE/README.txt
extracting: BDABaseImage-ol6-2.5.0_RELEASE/BDABaseImage-ol6-2.5.0_RELEASE.md5sum
inflating: BDABaseImage-ol6-2.5.0_RELEASE/ubiosconfig
前の手順で作成したサブディレクトリに移動します。
$ cd BDABaseImage-ol6-2.5.0_RELEASE
クラスタのイメージを変更します。
./reimagecluster
コマンドの完全な構文は、reimageclusterを参照してください。
Mammothを実行します。「単一ラックまたはプライマリ・ラックへのソフトウェアのインストール」を参照してください。
個別パッチ・バンドルは、1つ以上のリリースの特定の不具合に対する修正を提供します。Mammothを使用してクラスタにパッチを適用します。
個別パッチ・バンドルをインストールするには、次の手順を実行します。
自動リリース更新(ARU)システムからパッチ・バンドルをOracle Big Data Applianceクラスタの第1ノードのディレクトリ(/tmpなど)にダウンロードします。
ファイルは、BDA-patch-release-patch.zipという名前です。この手順の例ではBDA-patch-2.2.1-123456.zipという名前を使用します。
ファイルを解凍します。次に例を示します。
# 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
手順2で作成したパッチ・ディレクトリに移動します。次に例を示します。
$ cd BDA-patch-2.2.1-123456
実行ファイルの内容を抽出します。次に例を示します。
$ ./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"
BDAMammothディレクトリに移動します。
$ cd /opt/oracle/BDAMammoth
パッチをインストールします。次に例を示します。
$ ./mammoth -p 123456
Mammothを使用するには、rootとして第1サーバーにログインし、/opt/oracle/BDAMammothディレクトリに移動する必要があります。構文は次のとおりです。
./mammoth option [rack_name] [extension_number]
このコマンドで、rack_nameはOracle Big Data Applianceラックの名前です。ラック名は、構成ファイル名に表示されているとおり(mammoth-rack_name[-extnumber].params)に最初のコマンドに正確に入力する必要があります。その後、rack_nameはデフォルトで前のmammothコマンドで指定されたラックになります。
あるラックのインストールを完了してから、別のラックのインストールを開始する必要があります。
例10-1 Mammothの構文例
次のコマンドでは、Mammothユーティリティのヘルプを表示します。
./mammoth -h
次のコマンドでは、ラックbda3に対して完全なインストールを実行します。
./mammoth -i bda3
このコマンドでは、設定中のラックに対してステップ2から6を実行します。
./mammoth -r 2-6
このコマンドは、ラック内拡張キットのnode07から数えて6つのサーバーを既存のクラスタに追加する、パラメータ・ファイルを生成します。
./mammoth -e node07 6
mammothコマンドの構文は、新しいラックとラック内拡張キットの構成をサポートします。Mammothバンドルを使用して、以前のリリースからアップグレードすることもできます。
Oracle Big Data Applianceのクラスタ・チェックを実行します。
クラスタに追加するサーバー・グループのパラメータ・ファイルを生成します。新しいサーバーがクラスタ外のラックにある場合、ファイル名はmammoth-rack_name.paramsになります。そうではない場合、Mammothは1から5のラック内拡張番号の入力を求め、名前に使用します(mammoth-bda1-1など)。
start_nodeは、追加されるグループの第1サーバーのクライアント・ネットワークのホスト名です。
number_of_nodesは、クラスタに追加するサーバー数です。数値は3の倍数である必要があります。
パラメータ・ファイルにパスワードは含まれていないため、Mammothの実行時に入力する必要があります。
コマンドの使用方法とステップのリストが含まれるコマンド・ヘルプを表示します。
すべての必須ステップを実行します。フル・ラックの場合は、-r 1-18と同じです。このオプションは、新しいラックを構成する場合や、クラスタにサーバー・グループを追加する場合に使用します。
rack_nameは、クラスタに追加する新しいサーバーのプライマリ・ラックの外部の場所を示します。
expansion_numberは、mammoth-rack-name.paramsファイルの名前に含まれる拡張番号を示します。-eオプションを参照してください。
Mammothのステップをリストします。
クラスタのソフトウェアを最新バージョンにアップグレードするか、個別パッチをインストールします。
エラーが発生しないかぎり、MammothのステップnからNまでを実行します。
プライマリ・ラックでステップnを実行します。同じクラスタ内の別のラックを指定するには、rack_nameを入力します。必要に応じてexpansion_numberを入力します。-eオプションを参照してください。
Mammothのバージョン番号を表示します。
次に、ソフトウェアのインストール時に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マスターを構成し、エージェントが証明書を発行するのを待機してその署名を自動化します。このステップでは、すべてのノードの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ログ・ファイルを確認できます。
最新のOracle Big Data Applianceイメージおよびシステム・パラメータ設定をインストールします。
ライセンス契約の要件に応じて、サード・パーティ・ライセンスをすべてのサーバーの/opt/oss/src/OSSLicenses.pdfにコピーします。
ライセンス契約の要件に応じて、サード・パーティ・ソフトウェアのソース・コードをすべてのサーバーの/opt/oss/src/にコピーします。
Mammothはソース・コードをOracle NoSQL Databaseクラスタにコピーしません。
MammothはOracle NoSQL Databaseクラスタの論理ボリュームを作成しません。
hdfsおよびmapredユーザーと、hadoopグループを作成します。また、oracleユーザーと、dbaおよびoinstallグループも作成します。
後のステップでインストールされる様々なパッケージによっても、インストール中にユーザーおよびグループが作成されます。
|
関連項目: ユーザーおよびグループの詳細は、『Oracle Big Data Applianceソフトウェア・ユーザーズ・ガイド』を参照してください。 |
NameNodeデータが設定されているディスクまたはノード全体で障害が発生した場合にこの重要な情報の損失を防ぐため、このデータを複数の場所にコピーします。
MySQL Databaseをインストールして構成します。このステップでは、Cloudera Managerで使用するためにnode03にプライマリ・データベースと複数のデータベースが作成されます。また、node02のバックアップ・データベースに対するプライマリ・データベースのレプリケーションも設定されます。
MammothはOracle NoSQL DatabaseクラスタにMySQL Databaseをインストールしません。
Cloudera's Distribution including Apache Hadoop (CDH)およびCloudera Managerのすべてのパッケージをインストールします。その後、node03でCloudera Managerサーバーを起動し、クラスタを構成します。
MammothはOracle NoSQL DatabaseクラスタにCDHまたはCloudera Managerをインストールしません。
すべてのノードのエージェントを起動し、すべてのCDHサービスを開始します。このステップの後、Hadoopインストール環境が完全に機能します。
Cloudera Managerは、node03のポート7180で実行されます。これは次のようにブラウザで開くことができます。
http://bda1node03.example.com:7180
この例では、bda1node02がnode02の名前で、example.comがドメインです。デフォルトのユーザー名とパスワードは、adminです(これはステップ16で変更されます)。
Oracle NoSQL Databaseクラスタでは、MammothはCDHサービスをインストールも開始もしません。
Oracle Big Data Appliance構成生成ユーティリティでこのオプションを選択した場合は、Oracle Big Data Connectorsのサーバー側コンポーネントをインストールします。Oracle Big Data Connectorsにはライセンスが別途必要です。オプションです。
Oracle NoSQL Databaseを使用するために割り当てられたクラスタに、Oracle NoSQL Databaseをインストールします。Enterprise Editionにはライセンスが別途必要です。
このオプションを選択した場合には、Oracle Big Data ApplianceでKerberos認証を構成します。Oracle Big Data Applianceでキー配布センターを設定している場合には、必要な前提条件はありません。それ以外の場合には、「インストールの前提条件」を参照してください。
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』を参照してください。 |
自動サービス・リクエスト(ASR)をインストールして構成します。オプションです。
このステップでは、次のことが実行されます。
必要なソフトウェア・パッケージをインストールします。
トラップ宛先を構成します。
監視デーモンを起動します。
ASRマネージャからアセットをアクティブ化するには、「ASRアセットの確認」を参照してください。
次のことが実行されます。
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マネージャでアセットをアクティブ化します。
em: Oracle Big Data Appliance用Oracle Enterprise Managerシステム監視プラグインに対するサポートをインストールします。
disk-encryption: ディスクにあるHadoopデータの暗号化を有効にします。ディスクにすでに格納されているHDFSデータは、クラスタ内のすべてのサーバーでパラレルに読込み、暗号化および再書込みされます。データの量に応じて、このプロセスは完了までに数時間かかる場合があります。
「インストールの前提条件」と「オプション・ソフトウェアの構成の変更」を参照してください。
次の例では、クラスタ内のすべてのサーバーに自動サービス・リクエスト・サポートを追加します。
# cd /opt/oracle/BDAMammoth # ./mammoth-reconfig add asr
クラスタからサービスを削除します。parameterはサービスを識別するキーワードです。
em: Enterprise Managerのクラスタおよび名前付き資格証明、Oracle Big Data Applianceサーバーのエージェントを含む、Oracle Enterprise Managerシステム監視プラグインに対するサポートを削除します。Enterprise Managerスーパー管理ユーザーのパスワードを指定する必要があります。
disk-encryption: クラスタ内のすべてのサーバー上のHDFSデータをパラレルに読込み、復号化および再書込みします。データの量に応じて、このプロセスは完了までに数時間かかる場合があります。
nosql: Oracle NoSQL Databaseのインストールを、Oracle Big Data Appliance 2.1以前のクラスタのデータを含め、完全に削除します。これらのクラスタでは複数のディスクで縦型のパーティションが使用されていましたが、リリース2.2以降は使用されていません。アップグレードを実施する前に縦型のパーティションを削除する必要があります。
|
注意: nosqlオプションは、Oracle NoSQL Databaseに格納されているすべてのデータを削除します。使用する前に、Oracle NoSQL Databaseの標準の手順を使用してデータをバックアップしてください。 |
次の例では、クラスタ内のすべてのサーバーからOracle Enterprise Managerサポートを削除します。
# cd /opt/oracle/BDAMammoth # ./mammoth-reconfig remove em
クラスタからサービスの構成を変更します。parameterはサービスを識別するキーワードです。
次のユーティリティは、ベース・イメージのバンドルで配布されています。ユーティリティを実行するには、rootとしてログインする必要があります。
単一のサーバー、クラスタ、またはラック全体にベース・イメージを再インストールします。reimageclusterとreimagerackのどちらもこのユーティリティを呼び出します。
makebdaimageユーティリティには次の構文があります。
makebdaimage [--usb | --usbint] [--noiloms] /path/BDABaseImage-version_RELEASE.iso /path/BDdaDeploy.json target_servers
オプション
イメージの変更に使用するUSBポートを指定します。外部USBドライブの場合は--usb、内部ドライブの場合は--usbintを使用します。内部USBドライブにはLinuxの完全インストールが含まれます。
--usbintオプションを使用するには、ターゲット・サーバーにログインしている必要があります。ログインしていないと、間違ったネットワーク情報を使用してサーバーのイメージを変更する可能性があります。
イメージの変更処理によって、ターゲット・サーバー上のOracle ILOMが変更されることはありません。
イメージをインストールする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ファイルはそのまま使用されます。
dcliとmakebdaimageを使用して、クラスタ内のすべてのサーバーのイメージを同時に変更します。
reimageclusterユーティリティには次の構文があります。
reimagecluster [--no-iloms] [from.json [to.json]]
前提条件
次のコマンドがクラスタ内のサーバーのリストを返すことを確認します。
$ dcli -C hostname
BDABaseImage-version_RELEASE*.isoファイルが現在のディレクトリに1つだけあることを確認します。
オプション
イメージの変更処理によって、ターゲット・サーバー上のOracle ILOMが変更されることはありません。
現在の構成ファイル(BdaShip.jsonまたはBdaDeploy.json)へのフルパスです。
このオプションのデフォルト値は、/opt/oracle/bda/BdaDeploy.jsonです。BdaDeploy.jsonが見つからない場合、オプションのデフォルト値は、/opt/oracle/bda/BdaShip.jsonです。サーバーは事前にreimageclusterで使用されているJSONファイルの値に設定されている必要があります。
イメージの変更後に有効になる新しいネットワーク構成へのフルパスです。BdaDeploy.jsonファイルまたはBdaShip.jsonファイルのいずれかになります。
dcliとmakebdaimageを使用して、ラック内のすべてのサーバーのイメージを同時に変更します。
reimagerackユーティリティには次の構文があります。
reimagerack [--no-iloms] [--no-macs] [--hosts n1, n2...] [from.json [to.json]]
前提条件
次のコマンドがラック内のサーバーのリストを返すことを確認します。
$ dcli -hostname
BDABaseImage-version_RELEASE*.isoファイルが現在のディレクトリに1つだけあることを確認します。
オプション
イメージの変更処理によって、ターゲット・サーバー上のOracle ILOMが変更されることはありません。
このユーティリティはサーバーのMACアドレスを取得しません。かわりに、インフィニバンドのケーブル配線を使用します。このオプションは、工場出荷時の設定を復元する場合にのみ使用します。コマンドラインに両方のJSONファイル(from.jsonとto.json)が含まれている必要があります。
ホスト名またはIPアドレスのカンマ区切りのリストのうち、dcliが受け入れたいずれかのリストで指定されたサーバーのイメージの変更を制限します。すべてのサーバーは、dcli -tコマンドで指定されたターゲット・サーバーのリストに含まれている必要があります。
このオプションでは--no-macsオプションが強制的に実行されるため、その制限も適用されます。
現在の構成ファイル(BdaShip.jsonまたはBdaDeploy.json)へのフルパスです。
このオプションのデフォルト値は、/opt/oracle/bda/BdaDeploy.jsonです。BdaDeploy.jsonが見つからない場合、オプションのデフォルト値は、/opt/oracle/bda/BdaShip.jsonです。サーバーは事前にreimagerackで使用されているJSONファイルの値に設定されている必要があります。
イメージの変更後に有効になる新しいネットワーク構成へのフルパスです。BdaDeploy.jsonファイルまたはBdaShip.jsonファイルのいずれかになります。
