| Oracle® Big Data Applianceオーナーズ・ガイド リリース2 (2.2.1) E48216-02 |
|
 前 |
 次 |
この章では、Oracle Big Data Applianceのソフトウェアをインストール、再インストールまたは再構成する方法について説明します。この章の内容は次のとおりです。
|
注意: Mammothではパスワードが保存されないため、各パスワードの入力を求められます。オペレーティング・システムの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 Enterprise Managerオプションは、Oracle Big Data Applianceと同じネットワークのリモート・サーバーにソフトウェアが必要です。Mammothユーティリティを実行する前にそれらのインストールが完了している必要があり、そうでない場合は失敗します。
自動サービス・リクエストの前提条件は、次のとおりです。
My Oracle Supportアカウントが設定されている。
ASRマネージャが正常に稼働している。
Enterprise Managerの前提条件は、次のとおりです。
Oracle Mangement System (OMS)バージョン12.1.0.3.0以上が正常に稼働している。
OMSエージェント・プルURLが動作している。
OMS emcliダウンロードURLが動作している。
HTTPSアップロード・ポートとコンソール・ポートの両方が開いている。
|
注意: OMS資格証明を再確認し、Mammothユーティリティの実行時に正確に入力してください。Enterprise Managerの検出プロセスの失敗の主な原因は、無効な資格証明です。 |
Mammothバンドルには、Oracle Big Data Appliance構成ユーティリティ・スプレッドシート、インストール・ファイル、およびベース・イメージが含まれます。ソフトウェアをインストールする前に、第4章の説明に従って、構成ユーティリティを使用して構成ファイルを生成する必要があります。
ラック・サイズや、CDHまたはOracle NoSQL Databaseクラスタを作成しているか、または既存のクラスタをアップグレードしているかにかかわらず、この章で説明されているすべての手順に同じバンドルを使用します。
Mammothバンドルをダウンロードするには、次の手順を実行します。
My Oracle Supportにログインして、ナレッジ・ベースで情報センターID 1445745.2を検索します。
リリース2.2.1ダウンロード・パッチp17344065を見つけます。
BDAMammoth ZIPファイルをクラスタの第1ノードの任意のディレクトリ(/tmpなど)にダウンロードします。ラックの構成に応じて、このノードはラックの下から数えて1番目、7番目または13番目のサーバーになる場合があります。マルチラック・クラスタの場合、このサーバーはプライマリ・ラックにあります。
2.2のパッチは、次の2つのファイルで構成されます。
p17344065_221_Linux-x86-64_1of2.zipにはMammothインストール・ファイルが含まれます。
p17344065_221_Linux-x86-64_2of2.zipにはベース・イメージが含まれます。
クラスタの第1ノードにrootとしてログインします。
ダウンロードしたzipファイルからすべてのファイルを解凍します。
# unzip p17344065_221_Linux-x86-64_1of2.zip Archive: p17344065_221_Linux-x86-64_1of2.zip inflating: README.txt creating: BDAMammoth-2.2.1/ inflating: BDAMammoth-2.2.1/BDAMammoth-2.2.1.run inflating: BDAMammoth-2.2.1/bda-configurator-2.2.1.ods $ unzip p17344065_221_Linux-x86-64_2of2.zip Archive: p17344065_221_Linux-x86-64_2of2.zip creating: BDABaseImage-2.2.1_RELEASE/ inflating: BDABaseImage-2.2.1_RELEASE/README.txt inflating: BDABaseImage-2.2.1_RELEASE/biosconfig inflating: BDABaseImage-2.2.1_RELEASE/ubiosconfig extracting: BDABaseImage-2.2.1_RELEASE/BDABaseImage-2.2.1_RELEASE.md5sum inflating: BDABaseImage-2.2.1_RELEASE/makebdaimage inflating: BDABaseImage-2.2.1_RELEASE/reimagerack inflating: BDABaseImage-2.2.1_RELEASE/BDABaseImage-2.2.1_RELEASE.iso inflating: BDABaseImage-2.2.1_RELEASE/reimagecluster
BDAMammoth-versionディレクトリに移動します。
# cd BDAMammoth-2.2.1
BDAMammoth-version.runからすべてのファイルを抽出します。
# ./BDAMammoth-2.2.1.run
Big Data Appliance Mammoth v2.2.1 Self-extraction
Checking for and testing BDA Base Image in /tmp
BDABaseImage-2.2.1_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 -f asrexacheck -d /opt/oracle.SupportTools
dcliの詳細は、第13章を参照してください。
ファイルのアクセス権限を変更します。
# dcli chmod 755 /opt/oracle.SupportTools/asrexacheck
スクリプトを実行します。
# dcli /opt/oracle.SupportTools/asrexacheck
Oracle Supportのリクエスト(SR)を保存してASRインストールを検証します。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 Grid Controlを使用してOracle Big Data Applianceを監視している場合、再検出を実行してハードウェアおよびソフトウェアの変更を特定します。
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を参照してください。
既存のクラスタの第1サーバーにある古いバージョンのOracle Big Data Appliance構成ユーティリティを使用して、クラスタを新しいラックに拡張します。
ステップごとに、各サーバーに実行されたアクションとステップが正常に完了したかどうかを示す詳細なログ・ファイルが生成されます。エラーが発生すると、スクリプトは停止します。その後、/opt/oracle/BDAMammoth/bdaconfig/tmpのログ・ファイルを確認できます。ログ・ファイル名の書式は次のとおりです。
STEP-i-yyyymmddhhmmss.log
この書式で、iはステップ番号で、yyyymmddhhmmssはファイルが作成された時刻(年、月、日、時間、分および秒)を示します。
問題を修正したら、全部または一部のステップを再実行できます。ステップをスキップしたり、順序を変更してステップを実行することはできません。
ソフトウェアをアップグレードする手順は、あるメジャー・リリースから別のメジャー・リリースにアップグレードする場合でも、単にパッチ・セットを適用する場合でも同じです。また、この手順は、Hadoopクラスタが1つのOracle Big Data Applianceラックで構成されていても、複数のラックで構成されていても同じです。
このプロセスによって、ファームウェア、オペレーティング・システム、CDH、JDKおよびOracle Big Data Connectors (事前にインストールされている場合)を含むソフトウェア・スタックのすべてのコンポーネントがアップグレードされます。
ソフトウェアのダウングレードはサポートされません。
|
注意: アップグレード・プロセスでは必要に応じてサービスが自動的に停止および開始されるため、クラスタはmammothコマンドの実行中は使用できません。 |
次の手順に従って、Oracle Big Data Applianceクラスタのソフトウェアをバージョン2.1、2.0または1.1からバージョン2.1にアップグレードします。
|
注意: この手順では、バージョン1.1ソフトウェアをCDH3からCDH4にアップグレードします。MapReduceプログラムのアップグレードは必要ありませんが、このアップグレードの後に再編集する必要があります。 |
前提条件
Mammothユーティリティによってパスワードが求められた場合、クラスタで現在有効な次のパスワードが必要です。
oracle
root
Cloudera Manager admin
MySQL Database admin
Oracle Data IntegratorのMySQL Database (Oracle Data Integratorエージェントがインストールされている場合)
|
注意: Oracle Big Data Appliance 2.2では、CDHクラスタ内のOracle NoSQL Databaseはサポートされません。2.2にアップグレードすると、Oracle NoSQL Databaseがデータを含めて完全に削除されます。Oracle NoSQL Database用の別のクラスタを作成する必要があります。 |
ソフトウェアをバージョン2.2にアップグレードするには、次の手順を実行します。
クラスタで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
Oracle Enterprise Manager Grid Controlを使用してOracle Big Data Applianceを監視している場合、再検出を実行してソフトウェアの変更を特定します。
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ソフトウェアをインストールする前にベース・イメージを最新のバージョンにアップグレードする場合、このベース・イメージを再インストールする必要があります。
ラックのすべてまたは一部のイメージを変更できます。ただし、クラスタ内のすべてのサーバーは同じイメージである必要があります。適切な手順を実行します。
この手順を実行して単一のサーバーのイメージを変更します。たとえば、次のように障害サーバーを交換する場合を見てみます。
|
注意: サーバーのイメージを変更すると、すべてのファイルとデータが消去されます。 |
単一のサーバーにベース・イメージを再インストールするには、次の手順を実行します。
My Oracle Supportから最新のベース・イメージをダウンロードして、イメージを変更するサーバーにコピーします。Mammoth 2.2バンドルと一緒にダウンロードしたベース・イメージを使用するか、個別の17054122ベース・イメージ・パッチをダウンロードできます。
「Mammothソフトウェア・デプロイメント・バンドルのダウンロード」を参照してください。同じ基本手順でMy Oracle Supportからベース・イメージ・パッチをダウンロードできます。
現在のカスタマ設定のイメージをサーバーに再適用するには、意図したネットワーク構成が/opt/oracle/bda/BdaDeploy.jsonに反映されていることを確認します。反映されていない場合は、Oracle Big Data Appliance構成ユーティリティを使用して新しいファイルを生成します。第4章を参照してください。
パーティションに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ファイルを解凍します。
$ unzip p17054122_220_Linux-x86-64.zip
Archive: p17054122_220_Linux-x86-64.zip
creating: BDABaseImage-2.2.0_RELEASE/
inflating: BDABaseImage-2.2.0_RELEASE/README.txt
inflating: BDABaseImage-2.2.0_RELEASE/biosconfig
inflating: BDABaseImage-2.2.0_RELEASE/ubiosconfig
extracting: BDABaseImage-2.2.0_RELEASE/BDABaseImage-2.2.0_RELEASE.md5sum
inflating: BDABaseImage-2.2.0_RELEASE/makebdaimage
inflating: BDABaseImage-2.2.0_RELEASE/reimagerack
inflating: BDABaseImage-2.2.0_RELEASE/BDABaseImage-2.2.0_RELEASE.iso
inflating: BDABaseImage-2.2.0_RELEASE/reimagecluster
「Mammothソフトウェア・デプロイメント・バンドルのダウンロード」を参照してください。同じ基本手順でMy Oracle Supportからベース・イメージ・パッチをダウンロードできます。
前の手順で作成したBDABaseImage-2.2.0_RELEASEディレクトリに移動します。
$ cd BDABaseImage-2.2.0_RELEASE
makebdaimageコマンドを使用してサーバーのイメージを変更します。次の例では、内部USBを含めたサーバー4のイメージを、2.2.0ベース・イメージからBdaDeploy.jsonのカスタム設定に変更しています。イメージを変更するサーバー(この場合、サーバー4)にログインしている必要があります。
./makebdaimage -usbint BDABaseImage-2.2.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から最新のベース・イメージをダウンロードして、イメージを変更するラックの第1サーバー(最下部)にコピーします。Mammoth 2.2バンドルと一緒にダウンロードしたベース・イメージを使用するか、個別の17054122ベース・イメージ・パッチをダウンロードできます。
「Mammothソフトウェア・デプロイメント・バンドルのダウンロード」を参照してください。同じ基本手順でMy Oracle Supportからベース・イメージ・パッチをダウンロードできます。
第1サーバーのSSH接続を確立して、rootとしてログインします。
既存のカスタマ・ネットワーク設定のイメージを再適用するには、意図したネットワーク構成が/opt/oracle/bda/BdaDeploy.jsonに反映されていることを確認します。反映されていない場合は、Oracle Big Data Appliance構成ユーティリティを使用して新しいファイルを生成します。第4章を参照してください。
パスワードなし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ファイルを解凍します。
$ unzip p17054122_220_Linux-x86-64.zip
Archive: p17054122_220_Linux-x86-64.zip
creating: BDABaseImage-2.2.0_RELEASE/
inflating: BDABaseImage-2.2.0_RELEASE/README.txt
inflating: BDABaseImage-2.2.0_RELEASE/biosconfig
inflating: BDABaseImage-2.2.0_RELEASE/ubiosconfig
extracting: BDABaseImage-2.2.0_RELEASE/BDABaseImage-2.2.0_RELEASE.md5sum
inflating: BDABaseImage-2.2.0_RELEASE/makebdaimage
inflating: BDABaseImage-2.2.0_RELEASE/reimagerack
inflating: BDABaseImage-2.2.0_RELEASE/BDABaseImage-2.2.0_RELEASE.iso
inflating: BDABaseImage-2.2.0_RELEASE/reimagecluster
次のように、前の手順で作成されたBDABaseImage-version_RELEASEディレクトリに移動します。
# cd BDABaseImage-2.2.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から最新のベース・イメージをダウンロードして、イメージを変更するクラスタの第1サーバーにコピーします。ファイルは任意のディレクトリにコピーできます(/tmpなど)。ダウンロードの場所については、My Oracle Support情報センターID 1445745.2を参照してください。
Mammoth 2.2バンドルと一緒にダウンロードしたベース・イメージを使用するか、個別の17054122ベース・イメージ・パッチをダウンロードできます。
ラック内のクラスタの構成に応じて、第1サーバーは下から数えて1番目、7番目、10番目または13番目になる場合があります。
第1サーバーのSSH接続を確立して、rootとしてログインします。
意図したネットワーク構成が/opt/oracle/bda/BdaDeploy.jsonに反映されていることを確認します。反映されていない場合は、Oracle Big Data Appliance構成ユーティリティを使用して新しいファイルを生成します。第4章を参照してください。
パスワードなし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ファイルを解凍します。
$ unzip p17054122_220_Linux-x86-64.zip
Archive: p17054122_220_Linux-x86-64.zip
creating: BDABaseImage-2.2.0_RELEASE/
inflating: BDABaseImage-2.2.0_RELEASE/README.txt
inflating: BDABaseImage-2.2.0_RELEASE/biosconfig
inflating: BDABaseImage-2.2.0_RELEASE/ubiosconfig
extracting: BDABaseImage-2.2.0_RELEASE/BDABaseImage-2.2.0_RELEASE.md5sum
inflating: BDABaseImage-2.2.0_RELEASE/makebdaimage
inflating: BDABaseImage-2.2.0_RELEASE/reimagerack
inflating: BDABaseImage-2.2.0_RELEASE/BDABaseImage-2.2.0_RELEASE.iso
inflating: BDABaseImage-2.2.0_RELEASE/reimagecluster
「Mammothソフトウェア・デプロイメント・バンドルのダウンロード」を参照してください。同じ基本手順でMy Oracle Supportからベース・イメージ・パッチをダウンロードできます。
前の手順で作成したBDABaseImage-バージョン_RELEASEディレクトリに移動します。
# cd BDABaseImage-2.2.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
このコマンドは、ラック内拡張キットのnode07から数えて6つのサーバーを既存のクラスタに追加する、パラメータ・ファイルを生成します。
./mammoth -e node07 6
次のコマンドでは、設定中のラックに対してステップ2から6を実行します。
./mammoth -r 2-6
mammothコマンドの構文は、新しいラックとラック内拡張キットの構成をサポートします。Mammoth 2.2.1バンドルを使用して2.2.0、2.1、2.0または1.1からアップグレードすることもできます。
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クラスタにコピーしません。
物理ディスクが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です(これはステップ15で変更されます)。
Oracle NoSQL Databaseクラスタでは、MammothはCDHサービスをインストールも開始もしません。
Oracle NoSQL Database Community EditionおよびOracle Big Data Connectorsのサーバー側コンポーネントをインストールします(これらのオプションがOracle Big Data Appliance構成ワークシートで選択されている場合)。Oracle NoSQL Databaseにはディスク領域を割り当てる必要があり、Oracle Big Data Connectorsは個別にライセンスされている必要があります。オプションです。
Oracle Enterprise Managerエージェントをインストールして構成します。オプションです。
このステップでは、次のことが実行されます。
「次の名前付き資格証明を作成します: 「スイッチ資格証明」、「ホスト資格証明」、「Cloudera Managerの資格証明」、「ILOM資格証明」
クラスタ拡張では、同じ資格証明が再使用されます。
Oracle Big Data ApplianceサーバーのOracle Big Data ApplianceおよびOracle Exadata Database Machineプラグイン・エージェントを管理サーバーにデプロイされた最新バージョンに更新します。
名前付き資格証明を使用してクラスタの検出を実行します。
自動サービス・リクエスト(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マネージャでアセットをアクティブ化します。インストール・プロセスによって、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: Enterprise Managerのクラスタおよび名前付き資格証明、Oracle Big Data Applianceサーバーのエージェントを含む、Oracle Enterprise Managerシステム監視プラグインに対するサポートを削除します。Enterprise Managerスーパー管理ユーザーのパスワードを指定する必要があります。
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
次のユーティリティは、ベース・イメージのバンドルで配布されています。ユーティリティを実行するには、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ファイルのいずれかになります。
