| Oracle® Big Data Applianceオーナーズ・ガイド リリース4 (4.9) E88301-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を使用すると、次のことを実行できます。
CDHまたはOracle NoSQL Databaseのクラスタを設定できます。
複数のラックにクラスタを作成できます。
Oracle Big Data Applianceのラックに複数のクラスタを作成できます。
同じラックまたは新しいラックの新しいサーバーにクラスタを拡張できます。
新しいソフトウェアでクラスタを更新できます。
ローリング・アップグレードは、3つのレプリカのうち1つのノードを常にアクティブにするシーケンスでクラスタのノードを再起動します。これにより、クラスタは一連の再起動全体でオンラインのままになることができます。その結果、クラスタの一部の(すべてではない)サービスをアップグレード中に中断せずにアクセス可能なままにすることができます。
ローリング・アップグレードは、CDH 4.1以降を実行しているインストールでのみ使用できます。
ペアとなっているノードを順次に再起動するとプロセスの時間が長くなるため、ローリング・アップグレードは、すべてのサーバーが同時に再起動される従来のMammothアップグレードよりも長時間かかります。Mammothノードと(一度に再起動される)クリティカル・ノードごとに4分に加えて、非クリティカル・ノードのペアごとに平均8から10分を見積もってください。
ローリング・アップグレードは自動で実行できます。各サーバーのアップグレード後の再起動に成功した場合、再起動イベントは、あるサーバーから次(または次のペア)のサーバーに自動的に「ロール」します。サーバー再起動時に更新でエラーまたは警告条件が検出された場合、プロセスは一時停止し、続行するかどうかを確認するプロンプトが表示されます。
Reboot of node mnode22bda08 had errors/warnings, do you wish to proceed anyway? [y/n]:
nを入力した場合:
問題を解決できるようにアップグレードが停止します。
準備ができたら、mammoth -pを使用してインストールを再開します。
yを入力した場合:
アップグレードが続行されます。
このプロンプトは、ノード・アップグレードごとに1回表示されます。ノードがすでに再起動されている(そしてプロンプトに対してすでに回答されている)場合、プロンプトを再度表示せずにアップグレードが続行されます。
ローリング・アップグレードが可能な場合
ローリング・アップグレードは、このドキュメントで説明する次のアップグレード・タスクのオプションです。
通常、「クラスタへのサーバーの追加」では、このプロセスでクラスタ停止時間は発生しません。ただ1つの例外は、1ラック・クラスタが初めて2番目のクラスタに拡張されるケースで、クラスタ拡張のために停止時間が発生します(このときにマスターの役割が追加のラックに移されます)。ただし、その後のクラスタ拡張では停止時間は必要なくなります。
ローリング・アップグレードがオプションの場合、Mammothではコンソールに次のメッセージが表示され、インストールをローリング・アップグレードとして続行するかどうかの選択を求められます。
You can choose a rolling upgrade or continue with a conventional upgrade. Rolling upgrades need a minimum replication factor of three (this is the default in Mammoth) to have full availability during the upgrade. Do you wish to perform a Rolling Upgrade? [y/n]:
注意:
プロンプトにyと入力してローリング・アップグレードを受け入れた場合、クラスタはプロセスにコミットされ、クラスタ内のすべてのノードのアップグレードは中断なしで完了するまで続行する必要があります。 ローリング・アップグレード時のサービス可用性
ローリング・アップグレードでは、HDFS High Availability (HDFS HA)を使用するように構成されているサービスは、クラスタ内の各ノードがアップグレードされて再起動されるときに継続的に使用可能なままになります。これらには、HDFS、YARNおよびZookeeperが含まれます。これらのサービスをアップグレード中に使用可能にするには、3以上のHadoopレプリケーション係数が必要です。その理由は、ローリング・アップグレードはノードをペアで再起動するためです。グローバル構成は個々のファイルに対して上書きされている可能性があるため、アップグレードは、レプリケーション係数がこの最小値を満たすかどうかを事前に判断できません。不十分なレプリケーション係数でもアップグレードは停止されませんが、その場合、HDFS HA対応のサービスでダウンタイムが発生することがあります。
ローリング・アップグレードでは、Clouderaサービスは2つのバッチで再起動されます。これは、アップグレード中にHDFSおよびその他のサービスへのアクセスを維持するものです。HDFS HAを使用するように構成されない、または構成できないサービスは、レプリケーション係数に関係なく、ローリング・アップグレード中に使用不能になることがあります。
Oracle Enterprise Managerオプションでは、Oracle Big Data Applianceと同じネットワークのリモート・サーバーにソフトウェアが必要です。Mammothを実行する前にそれらのインストールが完了している必要があり、そうでない場合は失敗します。
同様に、キー配布センター(KDC)がリモート・サーバーにインストールされている場合には、Kerberosに対してもいくつかの手順を完了する必要があります。Oracle Big Data ApplianceにKDCをインストールする場合、事前に行う手順はありません。
次の表では、すべてのインストール・オプションの前提条件について説明します。
自動サービス・リクエストの前提条件は、次のとおりです。
My Oracle Supportアカウントが設定されている。
ASRマネージャが正常に稼働している。
Enterprise Managerの前提条件は、次のとおりです。
Oracle Management System (OMS)バージョン12.1.0.4.0以上が正常に稼働している。
OMSエージェント・プルURLが動作している。
OMS emcliダウンロードURLが動作している。
HTTPSアップロード・ポートとコンソール・ポートの両方が開いている。
リモートKDCの場合のMIT Kerberosの要件:
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が正常に動作しないことがあります。
リモートKDCの場合のActive Directory Kerberosの要件
Active Directory Kerberosの要件は、MOS (My Oracle Support)に記載されています。
MOSドキュメント2013585.1および2029378.1を参照してください。
Mammothバンドルには、インストール・ファイルとベース・イメージが含まれます。ソフトウェアをインストールする前に、「構成ファイルの生成」の説明に従い、Oracle Big Data Appliance構成生成ユーティリティを使用して構成ファイルを生成する必要があります。
ラック・サイズや、CDHまたはOracle NoSQL Databaseクラスタを作成しているか、または既存のクラスタをアップグレードしているかにかかわらず、この章で説明されているすべての手順に同じバンドルを使用します。
Mammothバンドルをダウンロードするには、次の手順を実行します。
My Oracle SupportまたはAutomated Release Updates (ARU)のいずれかのダウンロード・サイトを見つけます。
My Oracle Support
My Oracle Supportにログインし、『Oracle Big Data Appliance Patch Set Master Note (Doc ID 1485745.1)』を検索します。
リストが表示されたら、このリリースのMammothバンドル・ソフトウェア・バージョンのリンクをクリックします。
表から該当するMammothパッチ・バンドルへのリンクを見つけてください。
ARU
ARUに接続します。
Patchesページで、「Product」にBig Data Appliance統合ソフトウェアおよび「Release」に適切なリリース番号を設定します。
「Search」をクリックします。
BDA Mammoth ZIPファイルをクラスタの第1ノードの任意のディレクトリ(/tmpなど)にダウンロードします。ラックの構成に応じて、このノードはラックの下から数えて1番目、7番目または13番目のサーバーになる場合があります。マルチラック・クラスタの場合、このサーバーはプライマリ・ラックにあります。
パッチは、p<patch_number>_Linux-x86-64_<file number>of<total number of files>.zipのラベルのファイルのセットで構成されます
クラスタの第1ノードにrootとしてログインします。
ダウンロードしたすべてのzipファイルからすべてのファイルを解凍します。次に例を示します。
$ unzip p<patch_number>_Linux-x86-64_1of4.zip
Archive: p<patch_number>_<version>_Linux-x86-64_1of4.zip
inflating: README.txt
creating: BDAMammoth-ol6-<version>/
...
BDAMammoth-<version>ディレクトリに移動します。
# cd BDAMammoth-ol6-<version>
BDAMammoth-<version>.runからすべてのファイルを抽出します。
# ./BDAMammoth-ol6-<version>.run
Big Data Appliance Mammoth v<version> Self-extraction
Checking for and testing BDA Base Image in /tmp
BDABaseImage-<version>_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/
Extracting BDA Extras
Removing temporary files
.
.
.
Please "cd /opt/oracle/BDAMammoth" before running "./mammoth -i <rack_name>"
#
Mammothソフトウェアの新規バージョンは/opt/oracle/BDAMammothにインストールされ、以前のバージョン(アップグレードの場合)は/opt/oracle/BDAMammoth/previous-BDAMammothに保存されます。
実行中のインストール・タイプに固有の手順に従います。
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クラスタを実行できます。
ソフトウェアをインストールするには、次の手順を実行します。
Oracle Big Data Applianceラックが/opt/oracle/bda/network.jsonに記述されたカスタム・ネットワーク設定に従って構成されていることを確認します。ラックがまだ工場出荷時のデフォルトIPアドレスに構成されている場合、最初に「ネットワークの構成」の手順に従ってネットワーク構成を実行します。
ソフトウェアがまだラックにインストールされていないことを確認します。ソフトウェアがインストールされており、アップグレードする場合は、手順6でmammoth -pオプションを使用します。
Mammothバンドルをダウンロードして解凍します。クラスタの第1サーバーにrootとしてログインする必要があります。
BDAMammothディレクトリに移動します。
# cd /opt/oracle/BDAMammoth
cluster_name-config.jsonを現在のディレクトリにコピーします。
適切なオプションを使用してmammothコマンドを実行します。次のサンプル・コマンドでは、すべてのステップが実行されます。
./mammoth -i rack_name
ベース・イメージのアップグレードが行われた場合、Mammothのインストール手順3の完了後に、再起動するように要求されます。
自動サービス・リクエストのサポートをインストールした場合は、「自動サービス・リクエストのインストールの確認」の手順を実行します。
サーバー上の別のCDHクラスタを構成するには、次の手順を実行します。
注意:
Mammothは、現在の構成を/opt/oracle/bda/install/stateディレクトリに格納します。このディレクトリのファイルは削除しないでください。クラスタにラックを追加するなど、Mammothをもう一度使用する必要がある場合に、この情報が不足していると実行が失敗します。
自動サービス・リクエストのインストールの確認
My Oracle Support (http://support.oracle.com)にログインします。
ドキュメントID 2103715.1のエンジニアド・システムASR構成チェック・ツール(asrexacheckバージョン4.x)に関するドキュメントを検索し、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 -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を続行します。
関連項目:
dcliの詳細:
Mammothユーティリティが失敗した場合は、次の手順を実行して問題を解決します。
関連項目:
『Oracle Big Data Applianceソフトウェア・ユーザーズ・ガイド』
サーバーを既存のクラスタに追加するには、Mammothユーティリティを使用してクラスタを新しいサーバーに拡張します。この目的にはOracle Big Data Appliance構成生成ユーティリティを使用しないでください。
クラスタの各ラックで、ラックがクラスタに提供できる最小サーバー数は3です。したがって、3サーバー以上を含む1つのグループを最初に追加する必要があります。最小の数を満たせば、その他の制限はありません。この後、ラックからクラスタに1つずつサーバーを追加することも、任意の数をまとめて追加することもできます。また、ラック上のすべてのサーバーにクラスタを同時に拡張することもできます。
同じラック(および同じクラスタ)にサーバーを追加すると、そのプロセスでクラスタの停止時間は発生しません。1ラック・クラスタが初めて2番目のクラスタに拡張されるとき、クラスタ拡張のために停止時間が発生します(このときにマスターの役割が追加のラックに移されます)。ただし、その後のクラスタ拡張では停止時間は必要なくなります。
新しいノードを既存のクラスタに追加する場合、エッジ・ノードをデコミッションする必要はありません。
新しいサーバー・ノードと古いサーバー・ノードの構成方法に大きな違いはありません。ただし、新しいノードのディスク容量が大きい場合、作成されるデータ・パーティションは、ディスク全体を使用するために対応して大きくなります。データ・ノードごとに使用可能な容量が異なる状況はHDFSによって処理されます。Oracle Big Data Applianceにより特別な構成が追加で実行されることはありません。
関連項目:
クラスタの追加サーバーにソフトウェアをインストールするには、次の手順を実行します。
作業を開始する前に:
Mammoth -eオプションの説明は、「Mammothソフトウェア・インストールおよび構成ユーティリティ」を参照してください。
すべてのサーバーで同じソフトウェア・バージョンが実行されていることを確認します。追加のサーバーは、既存クラスタより新しいOracle Big Data Applianceベース・イメージを持つことはできません。
単一のHadoopクラスタを構成するすべてのラックがケーブルで接続されていることを確認します。
rootとしてプライマリ・ラックのnode01に接続し、BDAMammothディレクトリに移動します。
cd /opt/oracle/BDAMammoth
注意: Mammothは常にプライマリ・ラックから起動してください。
サーバー・グループのパラメータ・ファイルを生成します。次の例では、ノード13から数えて6つのサーバーを追加します。
./mammoth -e node13 node14 node15 node16 node17 node18
同じラックまたは複数のラックにあるサーバーを指定できます。
ベース・イメージのアップグレードが行われた場合、Mammothのインストール手順3の完了後に、再起動するように要求されます。
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以上をインストールする必要があります。
ソフトウェアをアップグレードする手順は、あるメジャー・リリースから別のメジャー・リリースにアップグレードする場合でも、単にパッチ・セットを適用する場合でも同じです。また、この手順は、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コマンドの実行中はクラスタを使用できません。ローリング・アップグレードの利点は、アップグレード・プロセス全体を通じて一部のサービスに中断なくアクセスできることです。ただし、ローリング・アップグレードはサーバーの再起動が同時に行われないため、サーバーごとに時間が余分にかかります。
現在、Oracle Big Data Applianceソフトウェアをアップグレードしても、対応するInfiniBandまたはCiscoスイッチのアップグレードは必要ありません。
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クラスタのソフトウェアを現在のバージョンにアップグレードします。
Mammothユーティリティによってパスワードが求められた場合、クラスタで現在有効な次のパスワードが必要です。
oracle
root
Cloudera Manager admin
MySQL Database admin
Oracle Data IntegratorのMySQL Database (Oracle Data Integratorエージェントがインストールされている場合)
Oracle Big Data Appliance 4.1では、Apache SentryはファイルベースのプロバイダからSentryサービスへ変更されました。クラスタをアップグレードするときにSentryが有効な場合、ファイルベースのプロバイダが維持されます。Sentryサービスへ切り替えるには、ソフトウェアをアップグレードする前にSentryを無効にし、後でSentryを再び有効にします。
次のようにOracle Big Data Applianceソフトウェアを現在のソフトウェア・バージョンにアップグレードします。これはサマリーです。次の手順の詳細、既知の問題および前提条件は、My Oracle SupportのDoc ID 2101906を参照してください。
注意:
アップグレードの前にすべてのOozieジョブを停止する必要があります。そうしないとアップグレードが失敗することがあります。当然のことながら、Oracle Big Data Applianceソフトウェア用のOracleの個別パッチはサポートされています。 個別パッチの一環として行われないパーセルのアップグレードは、Oracleサポートの承認がないかぎり、サポートされません。
Mammothバンドルには、Cloudera's Distribution including Apache Hadoop (CDH)のパーセルの最新のバージョンが含まれています。ただし、CDHはClouderaのスケジュールに合わせてリリースされており、現在のMammothバンドルよりも新しいCDHのリリースが利用できる場合があります。新しいバージョンのCDHが、現在のOracle Big Data Applianceリリースとの統合のためにサポートされている可能性があります。疑問がある場合は、Oracleサポートに問い合せてください。
現時点では、Oracle Linux 5でOracle Big Data Applianceクラスタを制限なしで引き続き完全サポートしています。安定性とパフォーマンスを高め、使用可能なアプリケーションの最新のエコシステムの規模と数を拡大して活用するには、クラスタをOracle Linux 6にアップグレードすることをお薦めします。オラクル社では、今後数回のリリースで、Oracle Linux 5でのOracle Big Data Applianceクラスタのサポートを段階的に廃止し、最終的には、Oracle Linux 5クラスタのアップグレードのサポートを終了します。
Oracle Big Data Appliance 4.9 for Linux 5では、アップグレードをサポートするスクリプトのセットが提供されます。これらのアップグレード・スクリプトでは、一度に1つのノードで実行する必要があり、重要性の低いノードから開始して、重要なノードに進み、プライマリ・ノード(Mammothが実行されるノード)で終了します。プライマリ・ノードは一般にノード1です。プライマリ・ノードで最後にスクリプトを実行することが重要です。
準備手順として、Oracle Big Data Applianceリリース4.9 for Linux 5のデプロイメント・バンドルをダウンロードしてインストールする必要があります。次に、リリース4.9 for Linux 6をダウンロードして、アップグレードを開始します。このバンドルは、通常の方法ではインストールされません。アップグレード・プロセスを開始するには、そのコンポーネントを使用するコマンドを実行します。クラスタの各ノードでOSアップグレード・スクリプトのセットを実行することで、アップグレードを完了します。これにより、クラスタがOracle Big Data Appliance 4.9 for Oracle Linux 6に実際に更新されます。これ以降は、Oracle Big Data Appliances for Oracle Linux 6の将来のリリースをインストールできるようになります。
このアップグレードはCDHクラスタ専用です。Oracle NoSQL Databaseクラスタには適用されません。
HDFSデータおよびCloudera Managerのロールはアップグレードで保持されます。
保存データの暗号化を使用したノードのアップグレードは現時点ではサポートされない
Oracle Linux 5からOracle Linux 6へのアップグレードは、Oracle Big Data Applianceに存在する可能性のある、保存データの2つのタイプの暗号化のいずれかを使用するノードでは現在機能しません。
HDFS透過的暗号化。
HDFS透過的暗号化を使用したクラスタのサポートは、後日追加される予定です。この暗号化を無効にしてOSアップグレードに進み、その後再度有効化するか、HDFS透過的暗号化がサポートされるまで、OSアップグレードを延期するかを選択できます。
eCryptfs
eCryptfs暗号化を使用する場合は、eCryptfsをアンインストールして、OSアップグレードを実行してから、必要に応じて、HDFS透過的暗号化を使用してデータを再暗号化することをお薦めします。Oracle Big Data Applianceでは、eCryptfsのサポートは廃止されました。この暗号化ソフトウェアの削除は必須になっていませんが、Oracle Big Data Applianceでは、eCryptfsを有効化する方法を提供していません。
いずれかの形式の暗号化を削除していない場合、OSをアップグレードすると、それらを削除する必要がある旨のメッセージが表示され、エラーで終了します。
HTTPS/ネットワーク暗号化はOSアップグレードの影響を受けません。
アップグレードの前にODIおよびOracle Big Data SQLのアンインストール(無効化)が必要
ODI (Oracle Data Integrator)
OSアップグレードの前にODIをアンインストールしないと、アップグレードによってすべてのOSパッケージが削除されます。アップグレード後、ODI関連のプロセスは実行されなくなり、ODIに関連する構成データが失われます。
Oracle Big Data SQL
Oracle Big Data SQLがインストールされている場合、ノードでOSアップグレードを実行する前に、インストールのHadoop側をアンインストールする必要があります。インストールのデータベース・サーバー側をアンインストールする必要はありません。HadoopクラスタでOSアップグレード中にデータベース側は影響を受けませんが、アップグレードの進行中はHadoopのデータに対する問合せは機能しません。
アップグレード後に、Oracle Big Data ApplianceをHadoopクラスタに再インストールし、インストールのデータベース側と再接続します。HadoopクラスタにOracle Big Data SQLを再インストールした後に接続の問題が発生した場合は、データベース・サーバーでインストールの再構成を試み、2つの側を再度整合させることができます。『Oracle Big Data SQLインストレーション・ガイド』の./bds-database-install.sh --reconfigureに関する項を参照してください。
Oracle Big Data Appliance構成ユーティリティで生成された構成の一部として、MammothによってOracle Big Data SQLがインストールされた場合、またはbdacliで有効化された場合は、bdacliを使用して、クラスタ全体で無効化します。
# bdacli disable big_data_sql
setup-bdsコマンド(『Oracle Big Data SQLインストレーション・ガイド』で説明)を使用してOracle Big Data SQLがインストールされた場合は、uninstallパラメータを指定して同じコマンドを使用します。
# ./setup-bds uninstall bds-config.json
ヒント:
Oracle Big Data SQLのインストールに使用した方法が不明の場合は、bdacli disable big_data_sqlを安全に試行できます。失敗した場合、インストールは./setup-bdsスクリプトで実行された可能性があります。OSアップグレードの前に、Oracle Big Data SQLを削除していない場合、Oracle Big Data SQLを削除する必要がある旨のメッセージがプロセスで表示され、エラーで終了します。
その他の重要な考慮事項
OSアップグレード・プロセスではバックアップが実行されず、Mammothによってインストールされなかったソフトウェアは移行されません。
Mammothインストール・メカニズム以外のサード・パーティ・ソフトウェア製品をインストールしている場合は、アップグレード後に、バックアップとリストア、またはそれらのソフトウェアの再インストールを個別に準備する必要があります。これには、MammothによってインストールされないOracleソフトウェアと、Clouderaソフトウェア(Kudu、Kafka、Sparkなど、便宜上Mammothソフトウェア・デプロイメント・バンドルに含めることができるが、Mammothによってインストールされないソフトウェア)が含まれます。
ユーザーによってOracle Linux 5カーネルに追加されるOracle Linuxモジュールは、Oracle Linux 6インストールに移行されません。
このプロセスでは、バックアップする重要なファイルのリストが生成されます。独自のリストを追加することもできます。
移行の前に保存する必要のある非Hadoopデータを個別にバックアップするのはお客様の責任です。
重要なノード(一般にはノード1 - 4)のアップグレードでは、重要なサービスを必ず一時的に中断する必要がありますが、どの時点でもクラスタ全体がシャットダウンされることはありません。進行中のジョブは引き続き実行できます。Hadoop機能は部分的に残されるか、大部分を使用できます。プロセスのどの時点でサービスが停止されるかは、現在アップグレードを実行中のノードで実行されているサービスとロールによって異なります。Oracle Big Data Appliance 4.9の準備アップグレードでは、クラスタのダウンタイムが含まれます。
Oracle Big Data Applianceでのデータの3要素レプリケーションにより、重要性の低いノード(主にデータを格納するノード)のアップグレード中に、サービスが失われることはありません。クラスタでレプリケーション係数が3 (デフォルト)に設定されていることを確認します。そうでない場合は、アップグレードを実行中のノードのデータを一時的に使用できなくなる場合があります。
1ラック・クラスタとマルチラック・クラスタのノード全体のサービスとロールの分散には、いくつかの違いがあります。ノードでアップグレードを実行中に、ノードで実行中のサービスを使用できない場合は、クラスタのノードでアップグレードをどのように指定し、スケジュール設定しているかに原因がある可能性があります。これ以外は、1ラック・クラスタとマルチラック・クラスタのアップグレード・プロセスで特別な考慮事項はありません。
Kerberosセキュリティ構成およびHTTPS/ネットワーク暗号化の設定はアップグレードで保持されます。前述のように、HDFS透過的暗号化を使用するクラスタのアップグレードは、現在はサポートされていません。
アップグレードに必要な時間の見積り
クラスタ全体のOracle Big Data Appliance 4.9 mammothアップグレードを実行してから、ノードごとにOSをアップグレードする時間の合計が長くなる可能性があります。主な要因はクラスタのサイズです。次の表の見積りを使用し、計画に役立ててください。
Mammothによって実行されるOracle Big Data Appliance 4.9.0アップグレードの見積りには、システムの重要なメタデータのバックアップのオプションの手順は含まれません。
表10-1 Oracle Big Data ApplianceでOracle Linux 5からOracle Linux 6へのアップグレードを完了するまでの推定時間のガイドライン
| 手順 | 推定時間 |
|---|---|
| 1. Oracle Big Data Appliance 4.9.0 for Linux 5のインストール。 | 4時間。 |
| 2. Oracle Big Data Appliance 4.9.0 for Linux 6デプロイメント・バンドルのダウンロードとファイルの抽出。 | 無視可。最大10分。 |
| 3. Oracle Linux 5からOracle Linux 6へのOSアップグレード。 | 5時間/ノード。 |
ノードでのOSアップグレードには最大5時間かかる場合があるため、ノードがホストするサービスのダウンタイムの影響を最も抑えられる場合に、一部のノードを計画するようにしてください。
ノードでのOSアップグレード中に、ノードが"異常" (インタフェースで色分けされます)であるとCloudera Managerが検出してレポートすることが予想されます。これは正常であり、他のノードが正常であるとCMが示した場合は、アップグレードが進行中でも無視できます。
重要性の低いノード(一般にはノード5以上)
重要性の低いノードは、CMエージェント、HDFSデータ・ノード、YARNノード・マネージャ、Puppetスレーブなど、2番目に重要なサービスを大部分で実行するノードです。(これらのサービスが重要なノードでも実行されます。)重要性の低いノードの1つがオフラインになっても、残りの重要性の低いノードでリソース要求に対応できるため、その計算および記憶域リソースが失われても、クラスタには重大な影響は発生しません。
重要なノード(一般にノード1 - 4)
次の表に、ノード1 - 4の最も重要なサービスと、各ノードでのOSのアップグレード中に予想されるサービス中断について示します。
表10-2 OSアップグレード中の重要なノードのダウンタイムの影響
| ノード | このノードで実行されるサービスとロール | OSアップグレード中の機能ステータス |
|---|---|---|
ノード4 |
YARNリソース・マネージャ、HIVE、Hue、Oozieサーバー。 |
ノード4のリソース・マネージャのロールがアクティブの場合、ノード4のダウンタイム中に、ノード3のリソース・マネージャがスタンバイからアクティブに切り替わります。YARN機能は影響を受けません。ただし、HIVE、Hue UIおよびOozieにはアクセスできず、これらのサービスにジョブを送信できません。現在実行中のHIVE、HueおよびOozeのジョブは終了されませんが、ジョブ・ステータスは利用不可になる場合があります。 |
ノード3 |
Cloudera Managerサーバー、MySQLプライマリ、リソース・マネージャ、ジャーナル・ノード、ZooKeeper |
ノード3のOSのアップグレード中は、MySQLプライマリ・データベースは停止します。CMサービス(それによるCloudera Manager Webコンソール)も使用できなくなります。この時点でHadoopクラスタの構成を変更することはできません。MySQLプライマリは停止しているため、新しいHIVE、OozieおよびHueのジョブは送信できません。現在のジョブは引き続き実行されますが、ステータスは更新されません。 リソース・マネージャ、ジャーナル・ノードおよびZookeeperでは、高可用性をサポートしているため、他のノードで実行中の同じノードは、サービスが中断することなく引き続き機能します。 |
ノード2 |
MySQLバックアップ・データベース、HDFS名前ノード、フェイルオーバー・コントローラ、ジャーナル・ノード、ZooKeeperおよびKerberosスレーブKDC (MIT Kerberosが有効になっており、KDCがOracle Big Data Applianceで設定されている場合)。 |
実行される重要なサービスは、MySQL以外すべて高可用性のため、ノードが停止してもHadoopクラスタ機能は失われません。MySQL,の場合、MySQLプライマリ・データベースはノード3でまたアクティブです。 |
ノード1 |
Kerberos Master、KDC (MIT Kerberosが有効になっており、KDCがOracle Big Data Appliance上にある場合)、Sentry Server (Sentryが有効になっている場合)、HDFS名前ノード、Zookeeper、ジャーナル・ノード、フェイルオーバー・コントローラなど。 モード1は"Mammothノード"(Mammothユーティリティを実行)でもあります。また、yum repoノードでもあります。 |
ノード1のダウンタイム中は、Sentry機能のように、主要なMammoth操作を実行したり、クラスタ・チェック( 名前ノード、フェイルオーバー・コントローラ、ジャーナル・ノードおよびZookeeperは高可用性のため、これらのサービスは、クラスタの他のノードで引き続き機能します。 |
1ラック・クラスタとマルチラック・クラスタのノード間でのサービスの分散にいくつか違いがあります。各自のクラスタに最も近いレイアウトを判断するには、『Oracle Big Data Applianceソフトウェア・ユーザーズ・ガイド』のCDHソフトウェア・サービスについてに関する項の表を参照してください。
次の2つのファイル・リストは、バックアップ用のファイルを識別するために、OSアップグレードで使用されます。
/opt/oracle/bda/compmon/osupgrade_filelist
アップグレード前のバックアップに必要なファイルを識別します。このファイルは、クラスタのすべてのノードの同じパスに存在します。
/opt/oracle/BDAMammoth/bdaconfig/tmp/my_filelist
これは、オプションのバックアップ・ファイル・リストです。バックアップする追加のファイルがある場合は、指定したパスに作成します。同じmy_filelistを各ノードの/opt/oracle/BDAMammoth/bdaconfig/tmp/my_filelistにコピーしたり、ノードごとに異なるファイル・リストを作成できます。
この追加のファイル・リストをノードのアップグレードに含める場合は、ノードでアップグレード・スクリプトを実行する前に、適切に配置する必要があります。
my_filelistを移入するためのガイドライン
各行で、/opt/oracle/bda/compmon/osupgrade_filelistにリストされているのと同じ書式を使用して、バックアップするディレクトリまたはファイルの絶対パスを指定します。
my_filelistにリストできるファイルまたはディレクトリのタイプに制限はありません。ただし、次の注意事項に必ず従ってください。
注意:
2つのバックアップ・ファイル・リストで必ずクロスチェックし、my_filelistに入力するファイル・リストと、システム生成のosupgrade_filelistに入力するファイル・リストの間に競合が発生しないようにしてください。
my_filelistでは、osupgrade_filelistにすでに存在するファイルまたはディレクトリのリストをレプリケートしないでください。システム・ファイルまたはディレクトリを含めないでください。たとえば、/etcをmy_filelistにリストしないでください。その場合、重要なシステム・データを上書きしてしまう場合があります。
アップグレードでは、ファイルの容量が十分にある場所を評価して、バックアップ・ファイル(osupgrade_filelistとmy_filelistの両方にリストされます)をノードの12のディスク(/u01 - /u012)の1つにリストアします。合計ボリュームがディスクの使用可能な記憶域を超えるファイルのリストでmy_filelistをオーバーロードしないでください。バックアップからリストアする領域が十分にない場合、アップグレードは失敗します。
バックアップするファイルが大量にある場合は、ノードの外部の一時記憶域にファイルをオフロードすることを検討します。
次の手順に従い、Oracle Big Data Appliance 4.9.0をインストールし、クラスタをOracle Linux 5からOracle Linux 6にアップグレードします。
アップグレードの準備として、クラスタをOracle Big Data 4.9.0 Linux 5リリース・レベルまで引き上げます。次に、Oracle Big Data 4.9.0 Linux 6デプロイメント・バンドルをダウンロードしますが、このバンドルのコンポーネントは通常の方法ではインストールしないでください。かわりに、アップグレードに必要なファイルを抽出するコマンドを実行します。最後に、クラスタでのヘルス・チェックの実行後に、OSアップグレード・スクリプトのセットをクラスタの各ノードで実行します。これらのスクリプトでは、オペレーティング・システムをOracle Linux 6にアップグレードし、Mammothをインストールしたソフトウェアに関連する更新を適用します。
Oracle Big Data Applianceデプロイメント・バンドルのダウンロードとインストールの手順は、次の各項を参照してください。
OSアップグレードは、クラスタのすべてのノードで手動で実行する必要があります。各ノードが停止している場合、クラスタへの影響は、ノードで実行中のサービスとロールによって異なります。(「ノードのアップグレード時に影響を受けるサービスとロールの判断」を参照してください。)
このアップグレードは、MITまたはAD Kerberosで保護されていないクラスタと保護されているクラスタの両方で機能します。
1. Oracle Big Data Appliance 4.9.0 (Oracle Linux 5)へのアップグレード
Oracle Big Data Appliance 4.9 for Oracle Linux 5へのアップグレードの手順は、My Oracle Supportの『Oracle Big Data Applianceパッチ・セット・マスター・ノート』(Doc ID 1485745.1)を参照してください。
この場合は、Mammoth runコマンドに-osupgrade引数を指定しないでください。
imageinfoを実行し、クラスタのサーバーのイメージ・レベルをチェックします。(クラスタのすべてのノードが同じレベルであった場合でも、dcliユーティリティ内でimageinfoを実行して、クラスタのすべてのノードをチェックできます。)以前のバージョンで実行されている場合は、サーバーをOracle Big Data Applianceリリース4.9 for Oracle Linux 5に更新します。リリース4.9.0 for Oracle Linux 5は、アップグレードの開始点です。
[root@myclusternode01 ~]# imageinfo Big Data Appliance Image Info IMAGE_CREATION_DATE : Sun Dec 22 18:25:46 PST 2013 IMAGE_LABEL : BDA_2.4.0_LINUX.X64_RELEASE IMAGE_VERSION : 2.4.0 LINUX_VERSION : Oracle Linux Server release 5.8 KERNEL_VERSION : 2.6.39-400.212.1.el5uek BDA_RPM_VERSION : bda-2.4.0-1.el5 OFED_VERSION : OFED-IOV-1.5.5-2.0.0088 JDK_VERSION : jdk-1.7.0_25-fcs HADOOP_VERSION : 2.0.0-cdh4.5.0
Oracle Big Data Appliance 4.9.0 for Oracle Linux 5をダウンロードしてインストールします。
パッチのダウンロードおよびインストールの手順は、「ソフトウェア・デプロイメント・バンドルのダウンロード」の項を参照してください。
2. Oracle Big Data Appliance 4.9.0デプロイメント・バンドルfor Oracle Linux 6のダウンロードと必要なファイルの抽出
バンドルをダウンロードして解凍し、Mammoth runコマンドに-osupgrade引数を指定して実行し、アップグレードに必要なOracle Linux 6コンポーネントを抽出します。
My Oracle Supportで『Oracle Big Data Applianceパッチ・セット・マスター・ノート』(Doc ID 1485745.1)」を検索します。
パッチをプライマリ・ノード(通常はノード1)の/tmpにダウンロードし、このコマンドを実行して、必要なファイルを抽出します。
# ./BDAMammoth-ol6-<version>.run -osugrade
重要:
ファイルをOracle Big Data Applianceデプロイメント・バンドルから抽出する場合、通常はBDAMammoth-<version>.runを使用します。この場合は、追加の-osugrade引数を必ず指定してください。このバージョンのrunコマンドでは、Oracle Linux 6へのアップグレードに必要なファイルとパッケージを/opt/oracle/os_upgradeに移入します3. クラスタのヘルス・チェックの実行
クラスタ・チェック(mammoth -c)を実行し、クラスタが正常な状態であることを確認します。すべてのチェックで"SUCCESS"ステータスが返される必要があります。次に進む前に問題を解決します。
# mammoth -c
4. 各ノードでのインストール後アップグレード・スクリプトの実行(一度に1つずつ)
各クラスタ・ノードにログインし、次に示す順序で、次の3つのスクリプトをrootとして実行します。重要性の低いノードから開始し、重要なノードに戻ります。(一般にノード1 - 4が最も重要であるとみなされます。)
スクリプトは、各ノードの/opt/oracle/bda/compmonにあります。
注意:
このプロセスでは、ノードはオフラインになってイメージが変更されてから、再起動されます。クラスタ内のサービスへの影響は、特定のノードで実行中のロールによって異なります。アップグレードするノードで追加のファイルをバックアップするために、カスタムosupgrade_filelistを作成した場合は、ノードの/opt/oracle/BDAMammoth/bdaconfig/tmpにコピーします。
bdadumpnode.shを実行します。
# ./opt/oracle/bda/compmon/bdadumpnode.sh
このスクリプトでは、特に、ロールとサービスを停止して、ファイルをバックアップします。
Hadoopおよび構成マネージャのロールと、現在のノードで実行中の特定のサービス(MySQL、Kerberosなど)を停止します。
osupgrade_filelistにリストされているファイル(およびユーザー定義の"my_filelist"ファイルにリストされているファイル)をローカル・ディスクのバックアップ・ディレクトリにバックアップします。
スクリプトが正常に完了していることを確認します。
エラーがない場合は、"bdadumpnode: Node dump completed successfully on host : <node name>"のメッセージが返されます
bdareimagenode.shを実行します。
# ./opt/oracle/bda/compmon/bdareimagenode.sh
このスクリプトでは、Oracle Linux 6 ISOで内部USBディスクをプロビジョニングし、12すべてのディスクのディスク・ラベルをDO_NOT_WIPEに設定します。次に、サーバーを再起動して、Oracle Linux 6へのイメージ変更を開始します。DO_NOT_WIPEが設定されている場合、イメージ変更で既存のデータ・パーティションが消去されることはありません。したがって、含まれるすべてのHDFSデータ・ブロックとHDFSデータは保持されます。
明らかなエラーもなくスクリプトが完了した場合は、/tmp/bdareimagenode-prepare-usb.outで追加のエラーのチェックを実行します。出力にエラーがない場合は、再起動に進みます。
# reboot
ノードのイメージ変更が完了すると、ノードはオンラインに戻ります。
OSのバージョン: # uname -rをチェックします
OSのバージョンは4.1.12-70.el6uek.x86_64である必要があります。
/rootディレクトリでファイルBDA_IMAGING_SUCCEEDEDまたはファイルBDA_IMAGING_FAILEDをチェックします。これらは、イメージ変更のステータスを示すフラグです。
イメージの変更が成功したら、サーバーをもう一度再起動します。
この2回目の再起動が完了したら、/rootでBDA_REBOOT_SUCCEEDEDまたはBDA_REBOOT_FAILEDをチェックします。
再起動が成功した場合は、bdarestorenode.shを実行できます。
# ./opt/oracle/bda/compmon/bdarestorenode.sh
このスクリプトでは、ノードを完全なサービスにリストアします。実行されるアクションは次のとおりです。
必要なパッケージ(Oracle Linux 6バージョン)の再インストール
バックアップからのすべてのファイルのリストア。
保存したメタデータのMySQLデータベースへのインポート。
Oracle Linux 6のパーセルからのCDHのインストール。
アップグレード前に実行していたすべてのロールのリストア。サーバーでは、クラスタ内で実行していたものと完全に同じ機能を再開します。
スクリプトを実行します。
スクリプトが成功したことを確認します。返されるメッセージは次のようになります。
“bdadumpnode: OS upgrade completed successfully on host : <mynode>”
関連項目:
付録「Oracle Linux 5からOracle Linux 6の移行スクリプトのサンプルの出力」では、bdadumpnode、badimagenodeおよびbdarestorenodeの出力の一般的なサンプルを示しています。4. クラスタ状態の再チェック
mammoth -cを再実行します。
構成マネージャをチェックし、ノードのすべてのサービスが青信号ですべてのロールが機能していることを確認します。
エラーがない場合、Oracle Big Data Appliance 4.9 for Oracle Linux 6へのアップグレードは完了しています。
Oracle Big Data Applianceの初期構成中に、オプションのソフトウェア・コンポーネントがインストールされる場合とインストールされない場合があります。bdacliユーティリティを使用して、この決定の一部を元に戻すことができます。関係のあるサーバー名、ポート、ユーザー名およびパスワードを指定する必要があります。
この項では、再構成オプションの例をいくつか示します。次の項目があります。
注意:
構文の詳細は、「bdacli」を参照してください。
Oracle Big Data Connectorsのサポートを追加または削除できます。
Oracle Big Data Connectorsのサポートを追加するとき、Oracle Data Integratorエージェントをインストールするかどうかを選択できます。インストールする場合は、MySQL DatabaseのrootユーザーおよびOracle Data Integratorユーザー(BDA_ODI_REPO)のパスワードを指定する必要があります。Cloudera Managerの管理ユーザーのパスワードがcluster_name-config.jsonに保存されていない場合、それも把握しておく必要があります。
次の手順では、bdacliユーティリティを使用します。
Oracle Big Data Connectorsをクラスタに追加する場合:
プライマリ・ラックの第1 NameNode (node01)にrootとしてログインします。
Oracle Big Data Connectorsを有効にします。
# bdacli enable bdc INFO: Logging all actions in /opt/oracle/BDAMammoth/bdaconfig/tmp/bda1node03-20140805110007.log and traces in /opt/oracle/BDAMammoth/bdaconfig/tmp/bda1node03-20140805110007.trc INFO: This is the install of the primary rack INFO: Checking if password-less ssh is set up . . . Do you wish to enable ODI? [y/n]: y Enter password for the BDA_ODI_REPO mysql user Enter password: odi_password Enter password again: odi_password Enter password for the mysql root user Enter password: root_password Enter password again: root_password WARNING: The password for the Cloudera Manager admin user is missing from the parameters file and is required for the installation. Enter password: admin_password Enter password again: admin_password % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 2 0 2 0 0 181 0 --:--:-- --:--:-- --:--:-- 250 INFO: Creating environment.pp file ... INFO: Making sure all puppet agents can be accessed. INFO: Pinging puppet agents INFO: Adding BDC to the cluster. This will take some time ... . . . SUCCESS: Successfully reconfigured service
Oracle Big Data Connectorsのサポートを削除する場合、次のユーザーのパスワードがcluster_name-config.jsonに保存されていないときは、それらのパスワードを指定する必要があります。
Cloudera Managerのadminユーザー
MySQL Databaseのrootユーザー(Oracle Data Integratorエージェントが有効になっている場合)
MySQL DatabaseのBDA_ODI_REPOユーザー(Oracle Data Integratorエージェントが有効になっている場合)
次の手順では、bdacliユーティリティを使用します。
Oracle Big Data Connectorsをクラスタから削除する場合:
プライマリ・ラックの第1 NameNode (node01)にrootとしてログインします。
Oracle Big Data Connectorsを削除します。
# bdacli disable bdc INFO: Logging all actions in /opt/oracle/BDAMammoth/bdaconfig/tmp/bda1node03-20140805104603.log and traces in /opt/oracle/BDAMammoth/bdaconfig/tmp/bda1node03-20140805104603.trc INFO: This is the install of the primary rack INFO: Checking if password-less ssh is set up INFO: Executing checkRoot.sh on nodes /opt/oracle/BDAMammoth/bdaconfig/tmp/all_nodes #Step -1# SUCCESS: Executed checkRoot.sh on nodes /opt/oracle/BDAMammoth/bdaconfig/tmp/all_nodes #Step -1# INFO: Executing checkSSHAllNodes.sh on nodes /opt/oracle/BDAMammoth/bdaconfig/tmp/all_nodes #Step -1# SUCCESS: Executed checkSSHAllNodes.sh on nodes /opt/oracle/BDAMammoth/bdaconfig/tmp/all_nodes #Step -1# INFO: Reading component versions from /opt/oracle/BDAMammoth/bdaconfig/COMPONENTS INFO: Creating nodelist files... WARNING: The password for the Cloudera Manager admin user is missing from the parameters file and is required for the installation. Enter password: admin_password Enter password again: admin_password % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 2 0 2 0 0 184 0 --:--:-- --:--:-- --:--:-- 250 WARNING: The password for the MySQL root user is missing from the parameters file and is required for the installation. Enter password: root_password Enter password again: root_password INFO: Executing verifyMySQLPasswd.sh on nodes /opt/oracle/BDAMammoth/bdaconfig/tmp/all_nodes #Step -1# SUCCESS: Executed verifyMySQLPasswd.sh on nodes /opt/oracle/BDAMammoth/bdaconfig/tmp/all_nodes #Step -1# WARNING: The password for the MySQL BDA_ODI_REPO user is missing from the parameters file and is required for the installation. Enter password: odi_password Enter password again: odi_password INFO: Executing verifyMySQLPasswd.sh on nodes /opt/oracle/BDAMammoth/bdaconfig/tmp/all_nodes #Step -1# INFO: Creating environment.pp file ... INFO: Making sure all puppet agents can be accessed. INFO: Pinging puppet agents INFO: Removing big data connectors. This will take some time ... . . . SUCCESS: Successfully reconfigured service
自動サービス・リクエストをサポートするには、次の手順を実行します。
My Oracle Supportアカウントを設定してASRマネージャをインストールします。これは、Oracle Big Data Applianceで自動サービス・リクエストをアクティブ化する前に行います。「自動サービス・リクエストの設定」を参照してください。
自動サービス・リクエスト監視を有効にしてアセットをアクティブ化します。
# bdacli enable asr INFO: Logging all actions in /opt/oracle/BDAMammoth/bdaconfig/tmp/bda1node01-20130205075303.log and traces in /opt/oracle/BDAMammoth/bdaconfig/tmp/bda1node01-20130205075303.trc . . . Enter the value for ASR_HOST [Default: ]: asr-host.example.com Enter the value for ASR_PORT [Default: 162]: Enter the value for ASR_SERVER_USER: jdoe Please Check the values you entered for the ASR parameters ASR_HOST = asr-host.example.com ASR_PORT = 162 ASR_SERVER_USER = jdoe Are these values correct (y/n): y Enter password for user jdoe on machine asr-host.example.com Enter password: password Enter password again: password INFO: Creating environment.pp file ... INFO: Making sure all puppet agents can be accessed. INFO: Pinging puppet agents INFO: Setting up ASR on all nodes. This will take some time ... . . .
「自動サービス・リクエストのインストールの確認」の手順を完了します。
Oracle Enterprise Manager Cloud Controlプラグインのインストール
予備パッチ(選択したプラグイン・バージョンに必要な場合)をインストールします。
| Enterprise Managerシステム・モニタリング・プラグイン | Oracle Big Data Applianceのプラグインをサポートするためのパッチ前提条件 |
|---|---|
| 13.2および13.2 PG Enterprise Manager System Monitoringプラグイン。 Oracle Big Data Applianceの場合、具体的な13.2 PGバージョンは |
パッチは必要ありません。 |
| 13.1 Enterprise Managerシステム・モニタリング・プラグイン |
|
| 12.c Enterprise Managerシステム・モニタリング・プラグイン |
|
Enterprise Managerシステム・モニタリング・プラグインをインストールします。
バージョン13.1のプラグインをインストールする手順は、Oracle Enterprise Manager System Monitoring Plug-inインストレーション・ガイドfor Oracle Big Data Applianceを参照してください。バージョン13.2および13.2 PGをインストールする場合も、これらと同じ手順を使用できます。
12.cプラグインのインストール手順の詳細は、My Oracle Supportのドキュメント(Download/Deployment of the 12c EM May Bundle Patch to Support Discovery/Monitoring of Cloudera Manager Admin Console HTTPS URLS (Doc ID 2148611.1))を参照してください。
13.2 PG for Oracle Big Data Applianceの新機能
13.2 PGプラグインfor Oracle Big Data Applianceでは、次のターゲットのサポートが追加されました。
Kafka
Sentry
Sqoop2
キー管理サービス
キー・トラスティ・サービス
クラスタ・セキュリティ
関連項目:
Oracle Big Data Applianceリリースの相互参照および互換性のあるOracle Enterprise Managerプラグインについては、My Oracle Supportの次のノートを参照してください。
『Oracle Enterprise Manager Cloud Control Big Data Applianceプラグイン互換性マトリクス(BDA V4.5以上)』(Doc ID 2267589.1)注意:
Active Directory Kerberosを有効にすることを選択した場合は、最初にMOS (My Oracle Support)ドキュメント2029378.1および2013585.1を読みます。これらのドキュメントでは、必要な準備手順について説明し、既知の問題に関する重要情報を提供しています。Kerberos認証をサポートするには、次の手順を実行します。
「インストールの前提条件」にリストされているKerberosの前提条件が完全に満たされていることを確認します。
プライマリ・ラックの第1 NameNode (node01)にログインします。
Kerberosを構成します。
# bdacli enable kerberos INFO: Logging all actions in /opt/oracle/BDAMammoth/bdaconfig/tmp/bda1node01-20131104072502.log and traces in /opt/oracle/BDAMammoth/bdaconfig/tmp/bda1node01-20131104072502.trc . . . INFO: Executing checkRoot.sh on nodes /opt/oracle/BDAMammoth/bdaconfig/tmp/all_nodes #Step -1# SUCCESS: Executed checkRoot.sh on nodes /opt/oracle/BDAMammoth/bdaconfig/tmp/all_nodes #Step -1# SUCCESS: Password-less root SSH is setup. Do you want to setup KDC on a BDA node (yes/no): yes Please enter the realm name: EXAMPLE.COM Enter password for Kerberos database: password Enter password again: password INFO: Executing changekrb5_kdc.sh on nodes bda1node01 #Step -1# SUCCESS: Executed changekrb5_kdc.sh on nodes bda1node01 #Step -1# SUCCESS: Successfully set the Kerberos configuration on the KDC INFO: Setting up Master KDC INFO: Executing setupKDC.sh on nodes bda1node01 #Step -1# . . .
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)からベース・イメージ・パッチをダウンロードして、イメージを変更するサーバーにコピーします。
注意:
ベース・イメージの最新のバージョン4.xを使用します。Mammothバンドルに含まれているバージョンは使用しないでください。
「Mammothソフトウェア・デプロイメント・バンドルのダウンロード」を参照してください。My Oracle Supportから基本イメージ・パッチをダウンロードするのと同じ基本手順を使用できます。
現在のカスタマ設定のイメージをサーバーに再適用するには、意図したネットワーク構成が/opt/oracle/bda/rack-network.jsonおよび/opt/oracle/bda/cluster-network.jsonに反映されていることを確認します。反映されていない場合は、Oracle Big Data Appliance構成生成ユーティリティを使用して新しいファイルのセットを生成します。「構成ファイルの生成」を参照してください。
/opt/oracle/bda/network.jsonの使用はまだサポートされていますが、推奨していません。)パーティションに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 p<number>_<version>_Linux-x86-64.zip Archive: p<number>_Linux-x86-64.zip creating: BDABaseImage-ol6-<version>_RELEASE/ creating: BDABaseImage-ol6-<version>_RELEASE/Extras/ creating: BDABaseImage-ol6-<version>_RELEASE/Extras/BALANCER/ extracting: BDABaseImage-ol6-<version>_RELEASE/Extras/BALANCER/orabalancer-<version>-h2.zip inflating: BDABaseImage-ol6-<version>_RELEASE/Extras/BALANCER/orabalancer-<version>-h2.noarch.rpm extracting: BDABaseImage-ol6-<version>_RELEASE/Extras/BALANCER/orabalancerdemo-<version>-h2.zip creating: BDABaseImage-ol6-<version>_RELEASE/Extras/CELL/ inflating: BDABaseImage-ol6-<version>_RELEASE/Extras/CELL/bd_cell-<version>_LINUX.X64_160506.11 ...
前の手順で作成したサブディレクトリに移動します。
# cd BDABaseImage-ol6-<version>_RELEASE
イメージを変更するサーバーにログインし、makebdaimageコマンドを実行します。次の例は、ベース・イメージから構成ファイルのカスタム設定にノード4のイメージを変更するコマンド(内部USBを含む)を示しています。rack-network.jsonおよびcluster-network.jsonをカンマで区切り、1つのパラメータとして送信します。
# ./makebdaimage -usbint BDABaseImage-<version>_RELEASE.iso /opt/oracle/bda/rack-network.json,/opt/oracle/bda/cluster-network.json 4
network.jsonファイル・パラメータとして送信することはできますが、推奨していません。
# ./makebdaimage -usbint BDABaseImage-<version>_RELEASE.iso /opt/oracle/bda/network.json 4
makebdaimageコマンドがエラーなしに成功した場合には、サーバーを再起動します。
注意:
ラック全体のイメージを変更すると、ラック上のすべてのクラスタ、ファイルおよびデータが消去されます。イメージの変更は、ソフトウェアのアップグレードには必要ありません。
ラックのすべてのサーバーにベース・イメージを再インストールするには、次の手順を実行します。
Oracle Big Data Applianceソフトウェアを以前にラックにインストールしている場合、Oracle Big Data Appliance以外の安全な場所に/opt/oracle/BDAMammoth/cluster_name-config.jsonファイルを保存します。
My Oracle SupportまたはOracle Automated Release Updates (ARU)から最新のベース・イメージ・パッチをダウンロードして、イメージを変更するラックの第1サーバー(最下部)にコピーします。
「Mammothソフトウェア・デプロイメント・バンドルのダウンロード」を参照してください。My Oracle Supportから基本イメージ・パッチをダウンロードするのと同じ基本手順を使用できます。
注意:
ベース・イメージの最新のバージョン4.xを使用します。Mammothバンドルに含まれているバージョンは使用しないでください。
第1サーバーのSSH接続を確立して、rootとしてログインします。
既存のカスタマ・ネットワーク設定のイメージを再適用するには、意図したネットワーク構成が/opt/oracle/bda/network.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ファイルを解凍します。次に例を示します。
# unzip p<number>_<version>_Linux-x86-64.zip Archive: p<number>_<version>_Linux-x86-64.zip creating: BDABaseImage-ol6-<version>_RELEASE/ inflating: BDABaseImage-ol6-<version>_RELEASE/biosconfig inflating: BDABaseImage-ol6-<version>_RELEASE/makebdaimage extracting: BDABaseImage-ol6-<version>_RELEASE/BDABaseImage-ol6-<version>_RELEASE.md5sum inflating: BDABaseImage-ol6-<version>_RELEASE/reimagerack inflating: BDABaseImage-ol6-<version>_RELEASE/reimagecluster inflating: BDABaseImage-ol6-<version>_RELEASE/BDABaseImage-ol6-<version>_RELEASE.iso . . .
前の手順で作成したサブディレクトリに移動します。
# cd BDABaseImage-ol6-<version>_RELEASE
次のいずれかの手順を完了します。
カスタマ・ネットワーク用に構成されたOracle Big Data Applianceにイメージを再適用して同じカスタマ・ネットワーク設定にするには、./reimagerackコマンドを実行します。
工場出荷時の設定を維持するアプライアンスのイメージに変更するには、次のようにします。
/opt/oracle/bda/network.jsonが存在しないことを確認します。
./reimagerackコマンドを実行します。
カスタム・ネットワーク設定を使用して構成されたラックで工場出荷時のネットワーク設定をリストアするには、次のようにします。
Oracle Big Data Appliance以外の安全な場所に/opt/oracle/bda/network.jsonをコピーします。
/opt/oracle/bda/BdaShip.jsonが存在することを確認します。
ラックのイメージを変更します。
./reimagerack deploy ship
Mammothを実行します。
関連項目:
reimagerackコマンドの完全な構文については、reimagerack。
Mammothの実行の手順については、「ソフトウェアのインストール」。
この手順を実行して、Mammothユーティリティが単一クラスタとしてデプロイしたサーバー・グループのイメージを変更します。Mammothが単一クラスタとしてデプロイしたサーバー・グループでのみ使用できます。現在のネットワーク設定を再適用することも、工場出荷時の設定に戻すこともできます。
注意:
クラスタのイメージを変更すると、クラスタ上のすべてのファイルとデータが消去されます。イメージの変更は、ソフトウェアのアップグレードには必要ありません。
必須の前提条件
Oracle Big Data Appliance構成ユーティリティで生成されたファイル<rack_name>-rack-network.jsonおよび<cluster_name>-cluster-network.jsonの名前をrack-network.jsonおよびcluster-network.jsonにそれぞれ変更する必要があります。つまり、ラック名とクラスタ名の接頭辞と最初のハイフンを取ります。これらの接頭辞の唯一の目的は、構成ユーティリティの出力でクラスタまたはラックを区別することです。
重要:
イメージを変更する前に、/opt/oracle/bda/rack-network.jsonおよび/opt/oracle/bda/rack-network.jsonがクラスタのすべてのノードに存在している必要があります。クラスタ内のすべてのサーバーのベース・イメージを再インストールするには、次の手順を実行します。
ヒント:
reimageclusterユーティリティは、ラックの各サーバーの内部USBドライブにインストーラを作成し、インストールを初期化して各サーバーを再起動します。サーバーが再起動のために停止している間、Integrated Lights Out Manager (ILOM)を使用して各サーバーにログオンし、進捗を監視できます。 <server name>-ilom.<domain>.com
「Remote Control」、「Redirection」、「Launch Remote Console」の順にクリックし、イメージの変更をモニタリングするJavaコンソールを起動します。
Oracle Big Data Applianceソフトウェアを以前にラックにインストールしている場合、Oracle Big Data Appliance以外の安全な場所に/opt/oracle/BDAMammoth/mammoth-<rack_name>.paramsファイル(または/opt/oracle/BDAMammoth/<cluster_name>-config.json)を保存します。クラスタがアップグレードされている場合、ファイルは/opt/oracle/BDAMammoth/previous-BDAMammothディレクトリに存在している可能性があります。
Oracle Big Data Applianceベース・イメージのTARファイルをMy Oracle Supportから一時ディレクトリにダウンロードします。イメージを変更するクラスタの最初の(最も下にある)サーバーにコピーします。
イメージ変更を現在の設定に適用する場合は、意図したネットワーク構成が/opt/oracle/bda/rack-network.jsonおよびcluster-network.jsonに反映されていることを確認します。そうでない場合は、Oracle Big Data Appliance構成生成ユーティリティを使用して新しいファイルを生成します。
第1サーバーのSSH接続を確立して、rootとしてログインします。
パスワードなしSSHがクラスタに設定されていることを確認します(dcli -C hostnameがエラーなしで動作する必要があります)。設定されていない場合は、setup-root-ssh -Cを実行します。
# setup-root-ssh -C Enter root password: ... ... setup-root-ssh succeeded
dcli -C hostnameがエラーなしで実行されると、クラスタ内のすべてのOracle Big Data Applianceサーバーのホスト名が返されます。そうではない場合、「パスワードなしSSHの設定」の手順に従ってください。すべてのサーバーでdcli -C hostnameコマンドが正常に実行されるまで、作業を継続しないでください。
すべてのサーバーのルート(/)パーティションが4GB以上空いていることを確認します。
# dcli -C df -h / 10.xxx.xxx.xx: Filesystem Size Used Avail Use% Mounted on 10.xxx.xxx.xx: /dev/md2 459G 49G 387G 12% / 10.xxx.xxx.xx: Filesystem Size Used Avail Use% Mounted on ...
ダウンロードしたベース・イメージのZIPファイルを解凍します。次に例を示します。
# unzip p<number>_<version>_Linux-x86-64.zip Archive: p<number>_<version>_Linux-x86-64.zip creating: BDABaseImage-ol6-<version>_RELEASE/ creating: BDABaseImage-ol6-<version>_RELEASE/Extras/ creating: BDABaseImage-ol6-<version>_RELEASE/Extras/BALANCER/ extracting: BDABaseImage-ol6-<version>_RELEASE/Extras/BALANCER/orabalancer-<version>-h2.zip inflating: BDABaseImage-ol6-<version>_RELEASE/Extras/BALANCER/orabalancer-<version>-h2.noarch.rpm extracting: BDABaseImage-ol6-<version>_RELEASE/Extras/BALANCER/orabalancerdemo-<version>-h2.zip creating: BDABaseImage-ol6-<version>_RELEASE/Extras/CELL/ inflating: BDABaseImage-ol6-<version>_RELEASE/Extras/CELL/bd_cell-<version>_LINUX.X64_160506.11 ...
前の手順で作成したサブディレクトリに移動します。
# cd BDABaseImage-ol6-<version>_RELEASE
次の手順のいずれかに従って、Oracle Big Data Appliance全体のイメージを変更します。第1の方法は、既存の設定を維持することです。第2の方法は、工場出荷時の設定(Oracle Big Data Appliance Configuration Utility設定の前)に戻すことです。
既存のネットワーク設定のイメージの変更および維持
/opt/oracle/bda/に、network.jsonおよびBdaShip.jsonの両方がリストされていることを確認します。
# ls *.json network.json BdaShip.json
network.jsonがリストされていない場合、customer-specific network.jsonファイル(維持する構成を記述したファイル)を探します。まず、このファイルがネットワーク設定を正しく定義していることを確認します。定義していない場合は、Oracle Big Data Appliance構成生成ユーティリティを使用して新しいファイルを生成します。ファイルを/opt/oracle/bdaにコピーし、ファイル名をnetwork.jsonに変更します。
dcliコマンドを使用して、network.jsonをクラスタのすべてのノードにコピーします。
# dcli -C -f /opt/oracle/bda/network.json -d /opt/oracle/bda/
./reimageclusterコマンドを実行します。 このコマンドにより表示される出力の一部を次に示します。
# ./reimagerack Passwordless SSH set up to all hosts : xxx.xxx.xx.xx xxx.xxx.xx.xx xxx.xxx.xx.xx xxx.xxx.xx.xx xxx.xxx.xx.xx xxx.xxx.xx.xx Using /tmp/BDABaseImage-ol6-<version>_RELEASE/BDABaseImage-ol6-<version>_RELEASE.iso to re-image BDABaseImage-ol6-<version>_RELEASE.iso: OK Re-imaging to existing customer network settings FINAL CONFIRMATION : All of the following hosts will be completely erased, re-imaged and initialized including resetting of the iloms: xxx.xxx.xx.xx xxx.xxx.xx.xx xxx.xxx.xx.xx xxx.xxx.xx.xx xxx.xxx.xx.xx xxx.xxx.xx.xx Proceed [y/n]? y Running hardware checks on all nodes... ... Rebooting all servers Broadcast message from root@bda1node01.example.com (unknown) at 15:58 ... The system is going down for reboot NOW!
工場出荷時のネットワーク設定のイメージの復元
手順1で説明したように、/opt/oracle/bda/rack-network.jsonおよびcluster-network.jsonがOracle Big Data Applianceの外部の安全な場所にコピーされており、/opt/oracle/bda/BdaShip.jsonが存在することを確認します。
次のコマンドを使用して、クラスタのイメージを工場出荷時の設定に戻します。
# ./reimagecluster deploy ship
reimageclusterによる再起動が完了した後、setup-root-sshを実行し、ラックのすべてのサーバーとの接続を確立します。 dcliコマンドを使用してすべてのサーバーをもう一度再起動できるようにするには、この作業が必要です。# setup-root-ssh Enter root password: ... setup-root-ssh succeeded
dcli再起動コマンドを使用して、すべてのサーバーをもう一度再起動します。
# dcli reboot
ファイル/root/BDA_IMAGING_SUCCEEDEDおよび/root/BDA_REBOOT_SUCCEEDEDが、ラックの各サーバーに存在することを確認します。
# dcli ls -lrt /root/BDA_*
/root/BDA_REBOOT_SUCCEEDEDの日付およびタイムスタンプが、イメージ変更プロセスにおける再起動の時間に一致していることを確認します。ファイルは0バイトである場合も、INFOメッセージが含まれる場合もあります。
インストールされたベース・イメージのバージョンを確認します。
# imageinfo Big Data Appliance Image Info IMAGE_VERSION : <version> IMAGE_CREATION_DATE : Wed May 18 20:19:54 UTC 2016 IMAGE_LABEL : BDA_<version>_LINUX.X64_RELEASE LINUX_VERSION : Oracle Linux Server release <version> KERNEL_VERSION : 2.<version>.el6uek.x86_64 BDA_RPM_VERSION : bda-<version>-1.el6.x86_64 OFED_VERSION : OFED-IOV-<version> JDK_VERSION : jdk1.<version>-fcs.x86_64
Mammothユーティリティを起動し、システムをOracle Big Data Applianceの最新のバージョンにすることができるようになります。
関連項目:
このMOSノート『Oracle Linux 6での新規インストールおよび既存のインストールのプロビジョニングのためのOracle Big Data Applianceベース・イメージ・バージョン4.5.0』(Doc ID 2173434.1)では、イメージの変更の追加の詳細が記載されています
個別パッチ・バンドルは、1つ以上のリリースの特定の不具合に対する修正を提供します。Mammothを使用してクラスタにパッチを適用します。
個別パッチ・バンドルをインストールするには、次の手順を実行します。
自動リリース更新(ARU)システムからパッチ・バンドルをOracle Big Data Applianceクラスタの第1ノードのディレクトリ(/tmpなど)にダウンロードします。
ファイルは、BDA-patch-release-patch.zipという名前です。この手順の例では、BDA-patch-<version>-123456.zipの名前を使用します。
ファイルを解凍します。次に例を示します。
# unzip BDA-patch-<version>-123456.zip Archive: BDA-patch-<version>-123456.zip creating: BDA-patch-<version>-123456/ inflating: BDA-patch-<version>-123456/BDA-patch-<version>-123456.run inflating: BDA-patch-<version>-123456/README.txt
手順2で作成したパッチ・ディレクトリに移動します。次に例を示します。
$ cd BDA-patch-<version>-123456
実行ファイルの内容を抽出します。次に例を示します。
$ ./BDA-patch-<version>-123456.run Big Data Appliance one-off patch 123456 for v<version> Self-extraction Removing existing temporary files Generating /tmp/BDA-patch-<version>-123456.tar Verifying MD5 sum of /tmp/BDA-patch-<version>-123456.tar /tmp/BDA-patch-<version>-123456.tar MD5 checksum matches Extracting /tmp/BDA-patch-<version>-123456.tar to /opt/oracle/BDAMammoth/patches/123456 Removing temporary files Please "cd /opt/oracle/BDAMammoth" before running "./mammoth -p 123456"
BDAMammothディレクトリに移動します。
$ cd /opt/oracle/BDAMammoth
パッチをインストールします。次に例を示します。
$ ./mammoth -p 123456
Mammothにより、パッチをローリング・アップグレードとしてロードするかどうかを選択するプロンプトが表示されます。(「ローリング・アップグレードについて」を参照してください)
あるいは、bdacliコマンドを使用できます。「bdacli」を参照してください。
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
mammothコマンドの構文は、新しいクラスタの構成をサポートします。Mammothバンドルを使用して、以前のリリースからアップグレードすることもできます。
Oracle Big Data Applianceのクラスタ・チェックを実行します。
クラスタに追加するサーバーのリストのパラメータ・ファイルを生成します。次に、新しいノードをクラスタに追加して、必要なソフトウェアをノードにインストールします。
同じラックまたは複数のラックにあるリストのサーバーを指定できます。
再起動は、通常は新しいノードおよび工場出荷時の初回更新時のみに実行されます。
生成されるパラメータは、opt/oracle/BDAMammoth/<cluster_name>-config.json(<cluster-name>は拡張されるクラスタの名前です)です。パラメータ・ファイルにパスワードは含まれていないため、Mammothの実行時に入力する必要があります。クラスタ拡張では、拡張でノードのデフォルトのrootパスワードが必要になるため、拡張が完了するまでそのパスワードを保持してください。パスワードは後で必ず変更してください。
Oracle NoSQL Databaseクラスタでは、Mammothにより、新しいノードのゾーンの種類を要求されます。既存のゾーン、新しいプライマリ・ゾーンまたは新しいセカンダリ・ゾーンから選択できます。既存のゾーンに追加する場合は、使用できるゾーンの一覧が表示されます。新しいゾーンを作成する場合は、ゾーンの名前およびレプリケーション・ファクタを要求されます。
注意: Oracle Big Data SQLが有効になっている場合:
Oracle Big Data Appliance 4.9.0では、mammoth -eを実行しても、必要な変更がOracle Big Data SQLに加えられません。mammoth -eの実行後に、./setup-bds extend bds-config.jsonを呼び出して、問題を修正します。コマンドの使用方法とステップのリストが含まれるコマンド・ヘルプを表示します。
クラスタですべての必須ステップを実行します。フル・ラックの場合は、-r 1-18と同じです。このオプションは、新しいラックを構成する場合や、クラスタにサーバー・グループを追加する場合に使用します。
Mammothユーティリティのステップをリストします。
クラスタのソフトウェアを最新バージョンにアップグレードするか、個別パッチをインストールします。
エラーが発生しないかぎり、MammothのステップnからNまでを実行します。
ステップnを実行します。同じラックの別のクラスタを指定するには、cluster_nameを入力します。-eオプションを参照してください。
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クラスタにコピーしません。
hdfsおよびmapredユーザーと、hadoopグループを作成します。また、oracleユーザーと、dbaおよびoinstallグループも作成します。
後のステップでインストールされる様々なパッケージによっても、インストール中にユーザーおよびグループが作成されます。
関連項目:
ユーザーおよびグループの詳細は、『Oracle Big Data Applianceソフトウェア・ユーザーズ・ガイド』を参照してください。
NameNodeデータが設定されているディスクまたはノード全体で障害が発生した場合にこの重要な情報の損失を防ぐため、このデータを複数の場所にコピーします。
MySQL Databaseをインストールして構成します。このステップでは、Cloudera Managerで使用するためにnode03にプライマリ・データベースと複数のデータベースが作成されます。また、node02のバックアップ・データベースに対するプライマリ・データベースのレプリケーションも設定されます。
MammothはOracle NoSQL DatabaseクラスタにMySQL Databaseをインストールしません。
クラスタでセキュリティを設定するために使用されるKerberosキー配布センター(KDC)を構成します。
Cloudera's Distribution including Apache Hadoop (CDH)およびCloudera Managerのすべてのパケットをインストールします。その後、node03でCloudera Managerサーバーを起動し、クラスタを構成します。
MammothはOracle NoSQL DatabaseクラスタにCDHまたはCloudera Managerをインストールしません。
すべてのノードのエージェントを起動し、すべてのCDHサービスを開始します。HTTPS/ネットワーク暗号化が有効になっている場合は、Cloudera Manager、HueおよびOozieに対してもHTTPSを有効にします。
このステップの後、Hadoopインストール環境が完全に機能します。
Cloudera Managerは、node03のポート7180で実行されます。これは次のようにブラウザで開くことができます。
http://bda1node03.example.com:7180
この例では、bda1node02がnode02の名前で、example.comがドメインです。デフォルトのユーザー名とパスワードはadminです。パスワードはこのステップの最後に変更するように求められます。
Oracle NoSQL Databaseクラスタでは、MammothはCDHサービスをインストールも開始もしません。
Oracle Big Data Appliance構成生成ユーティリティでこのオプションを選択した場合は、Oracle Big Data Connectorsのサーバー側コンポーネントをインストールします。Oracle Big Data Connectorsにはライセンスが別途必要です。オプションです。
Oracle Big Data Appliance構成生成ユーティリティでこのオプションを選択した場合は、Oracle Big Data SQLのサーバー側コンポーネントをインストールします。Oracle NoSQL DatabaseのOracle Big Data SQLサポートの場合、このステップではCDHノードにクライアント・ライブラリ(kvclient.jar)をインストールします。Oracle Big Data SQLにはライセンスが別途必要です。オプションです。
Oracle NoSQL Databaseを使用するために割り当てられたクラスタに、Oracle NoSQL Databaseをインストールします。Enterprise Editionにはライセンスが別途必要です。
このステップで実行されるアクションは、インストールに先立ってOracle Big Data Appliance構成ユーティリティで行った選択に基づきます。
このオプションが選択されている場合は、HTTPS/ネットワーク暗号化を構成します。
このオプションが選択されている場合は、HDFS透過的暗号化を構成します。
Mammothは、インストールに先立って構成ユーティリティでローカルと外部のどちらのKey Trustee Serverを選択したかに応じて、HDFS透過的暗号化に必要なNavigator Key Trusteeサービスを設定します。
構成ユーティリティで「Setup Key Trustee Servers on the BDA」を選択した場合、MammothはOracle Big Data Appliance上でローカルにアクティブおよびパッシブKey Trustee Serverを設定します。
外部Key Trustee Serverを使用するように選択した場合、この設定で外部サーバーへの接続が構成されます(MOS Doc ID 2112644.1の説明に従って外部Navigator Key Trustee Serverがすでに構成されている必要があります)。
このオプションを選択した場合には、Kerberos認証を構成します。Oracle Big Data Applianceでキー配布センターを設定している場合には、前提条件はありません。それ以外の場合には、「インストールの前提条件」を参照してください。
自動サービス・リクエスト(ASR)をインストールして構成します。オプションです。
このステップでは、次のことが実行されます。
必要なソフトウェア・パッケージをインストールします。
トラップ宛先を構成します。
監視デーモンを起動します。
ASRマネージャからアセットをアクティブ化するには、「ASRアセットの確認」を参照してください。
注意:
このステップを正常に実行するには、ASRマネージャが実行され、適切に構成されたASRホスト・システムが稼働している必要があります。「自動サービス・リクエストの設定」を参照してください。
次のことが実行されます。
Cloudera Managerパスワードを変更します(インストール・テンプレートに指定されている場合)。
インストール中に作成された一時ファイルを削除します。
すべてのノードから/opt/oracle/bda/install/logのサブディレクトリにログ・ファイルをコピーします。
クラスタ検証チェック(TeraSortを含む)を実行して、すべてが適切に動作することを確認します。また、インストール・サマリーも生成されます。すべてのログは、node01の/opt/oracle/bda/install/log以下のサブディレクトリに格納されます。
「PreinstallChecks」で設定したrootのパスワードなしSSHを削除します。
次のユーティリティは、ベース・イメージのバンドルで配布されています。ユーティリティを実行するには、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の工場出荷時の構成またはnetwork.jsonのカスタム構成のいずれでもかまいません。構成されたサーバーの/opt/oracle/bdaにあります。
to.json: network.jsonやBdaShip.jsonに類似の連結されたJSONファイルですが、ETH0_MACSアレイ・エントリが追加されています。連結ファイルの最初のエントリと対応するeth0_macエントリがイメージを変更するときに使用されます。to.jsonファイルはそのまま使用されます。
dcliとmakebdaimageを使用して、クラスタ内のすべてのサーバーのイメージを同時に変更します。
reimageclusterユーティリティには次の構文があります。
reimagecluster [--no-iloms]
前提条件
次のコマンドがクラスタ内のサーバーのリストを返すことを確認します。
$ dcli -C hostname
BDABaseImage-version_RELEASE*.isoファイルが現在のディレクトリに1つだけあることを確認します。
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またはnetwork.json)へのフルパスです。
このオプションのデフォルト値は、/opt/oracle/bda/network.jsonです。network.jsonが見つからない場合、オプションのデフォルト値は、/opt/oracle/bda/BdaShip.jsonです。サーバーは事前にreimagerackで使用されているJSONファイルの値に設定されている必要があります。
イメージの変更後に有効になる新しいネットワーク構成へのフルパスです。network.jsonファイルまたはBdaShip.jsonファイルのいずれかになります。
