10 Oracle Big Data Applianceソフトウェアのインストール
この章では、Oracle Big Data Applianceのソフトウェアをインストール、再インストールおよび再構成する方法について説明します。この章の内容は次のとおりです。
ノート:
Oracle Big Data Appliance構成生成ユーティリティで必要なパスワードを入力しなかった場合、ソフトウェアのインストール時に入力するように要求されます。オペレーティング・システムのroot
およびoracle
ユーザー、Cloudera Managerのadmin
ユーザー、およびMySQL管理者の現在のパスワードを把握していることを確認してください。Oracle Big Data Connectorsをインストールまたは再インストールする場合、Oracle Data IntegratorのMySQLパスワードも必要です。
10.1 Mammothユーティリティについて
Mammothは、Oracle Big Data Applianceソフトウェアをインストールおよび構成するためのコマンドライン・ユーティリティです。Mammothを使用すると、次のことを実行できます。
-
CDHまたはOracle NoSQL Databaseのクラスタを設定できます。
-
複数のラックにクラスタを作成できます。
-
Oracle Big Data Applianceのラックに複数のクラスタを作成できます。
-
同じラックまたは新しいラックの新しいサーバーにクラスタを拡張できます。
-
新しいソフトウェアでクラスタを更新できます。
10.1.1 ローリング・アップグレードについて
ローリング・アップグレードとは、クラスタの停止時間を回避するアップグレード方法のことです。
ローリング・アップグレードは、3つのレプリカのうち1つのノードを常にアクティブにするシーケンスでクラスタのノードを再起動します。これにより、クラスタは一連の再起動全体でオンラインのままになることができます。その結果、クラスタの一部の(すべてではない)サービスをアップグレード中に中断せずにアクセス可能なままにすることができます。HUE、OozieおよびHiveServer2などの冗長性のないサービスでは、それらが実行されているノードが再起動される間に短い中断が発生します。また、MySQLマスター・ノードが再起動されるとき、Cloudera Manager、Hive、OozieおよびHUEで短い中断が発生します。
ノート:
リリース5.1へのアップグレードでは一部のクラスタで停止時間が必要となるため、Oracle Big Data Appliance 5.1ではローリング・アップグレードはサポートされていません。このアップグレード中に、ローリング・アップグレードと従来のアップグレードのいずれかを選択するように求められた場合は、従来のアップグレードを選択します。10.2 インストールの前提条件
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を参照してください。
10.3 Mammothソフトウェア・デプロイメント・バンドルのダウンロード
Mammothバンドルには、インストール・ファイルが含まれます。ソフトウェアをインストールする前に、「構成ファイルの生成」の説明に従い、Oracle Big Data Appliance構成生成ユーティリティを使用して構成ファイルを生成する必要があります。
ラック・サイズや、CDHまたはOracle NoSQL Databaseクラスタを作成しているか、または既存のクラスタをアップグレードしているかにかかわらず、この章で説明されているすべての手順に同じバンドルを使用します。
ノート:
Mammothソフトウェア・デプロイメント・バンドルには、ベース・イメージISOのコピーは含まれなくなりました。後からベース・イメージが必要になった場合は、次に示すMy Oracle Supportノートにダウンロード・リンクがあります: Oracle Big Data Appliance Patch Set Master Note (Doc ID 1485745.1)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-ol7-<version>/ ...
-
BDAMammoth-
<version
>ディレクトリに移動します。# cd BDAMammoth-ol7-<version>
-
BDAMammoth-
<version
>.run
からすべてのファイルを抽出します。# ./BDAMammoth-ol7-<version>.run Big Data Appliance Mammoth v<version> Self-extraction Checking for and testing BDA Package in /tmp 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 Package RPMs to bdarepo Moving BDAPackages 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
に保存されます。 -
実行中のインストール・タイプに固有の手順に従います。
10.4 新規ラックへのソフトウェアのインストール
Mammothユーティリティでは、Oracle Big Data Appliance構成生成ユーティリティによって生成されたファイルを使用して、Oracle Big Data Applianceにソフトウェアをインストールして構成できます。クラスタは、CDH (Hadoop)専用またはOracle NoSQL Database専用にできます。CDHとOracle NoSQL Databaseは同じクラスタ内で動作できません。
CDHクラスタの場合、MammothによってCloudera's Distribution including Apache Hadoopのインストールと構成が行われます。これには、すべてのHadoopソフトウェアおよびCloudera Manager (Hadoopクラスタを管理するためのツール)が含まれます。
NoSQLクラスタの場合、MammothはOracle NoSQL Databaseをインストールします。
Mammothは、Oracle Big Data Connectors、Oracle Big Data SQLなどの一部のオプションのOracleソフトウェアもインストールできます。
Mammothでは、ラック内のすべてのサーバーにソフトウェアをインストールする以外に、必要なユーザー・アカウントの作成、適切な構成パラメータの設定、およびクラスタでのサービスの開始を行うことができます。
10.4.1 ソフトウェアのインストール
ソフトウェアをインストールするには、次の手順を実行します。
-
Oracle Big Data Applianceラックが
/opt/oracle/bda/network.json
(またはcluster-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
の詳細:
10.6 クラスタへのサーバーの追加
Mammothインストーラを使用して、クラスタにサーバーを追加できます。
サーバーを既存のクラスタに追加するには、Mammothユーティリティを使用してクラスタを新しいサーバーに拡張します。この目的にはOracle Big Data Appliance構成生成ユーティリティを使用しないでください。
ノート:
- 1ラック・クラスタには、常に少なくとも3つのノードを含める必要があります。
- クラスタを第2ラックに拡張する場合は、クラスタおよび第1ラックには少なくとも4つのノードを含める必要があります。
- マルチラック・クラスタ内の第2ラックおよび後続のすべてのラックが、1つから任意の数のノードをクラスタに提供できます。
単一のクラスタまたは複数のクラスタのいずれでも、この処理でクラスタの停止時間は発生しません。
新しいノードを既存のクラスタに追加する場合、エッジ・ノードをデコミッションする必要はありません。
新しいサーバー・ノードと古いサーバー・ノードの構成方法に大きな違いはありません。ただし、新しいノードのディスク容量が大きい場合、作成されるデータ・パーティションは、ディスク全体を使用するために対応して大きくなります。データ・ノードごとに使用可能な容量が異なる状況は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
次に示すように、-r (範囲)または-s (ステップ)オプションをmammoth -e
と組み合せて使用することもできます。# mammoth -r 1-4 -e newnode1 newnode2 newnode3...
# mammoth -s 2 -e newnode1 newnode2 newnode3...
同じラックまたは複数のラックにあるサーバーを指定できます。
ベース・イメージのアップグレードが行われた場合、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でのソフトウェアのアップグレード」を参照してください。
イメージ・バージョンをダウングレードするには、次の手順を実行します。
-
新しいラックのイメージを、クラスタにインストールされている古いバージョンに変更します。
-
既存のクラスタの第1サーバーにある古いバージョンのMammothユーティリティを使用して、クラスタを新しいラックに拡張します。
関連項目:
再イメージ化の詳細は、「Oracle Big Data Applianceのインストールに関するよくある質問(FAQ) (Doc ID 1518939.1)」を参照してください。Oracle Big Data Applianceのよくある質問(DOC ID 1518939.1)
10.7 Oracle Big Data Applianceでのソフトウェアのアップグレード
ソフトウェアをアップグレードする手順は、あるメジャー・リリースから別のメジャー・リリースにアップグレードする場合でも、単にパッチ・セットを適用する場合でも同じです。また、この手順は、Hadoopクラスタが1つのOracle Big Data Applianceラックで構成されていても、複数のラックで構成されていても同じです。
このプロセスによって、ファームウェア、オペレーティング・システム、Oracle Linux Unbreakable Enterprise Kernel (UEK)、CDH、JDKおよびOracle Big Data Connectors (事前にインストールされている場合)を含むソフトウェア・スタックのすべてのコンポーネントがアップグレードされます。
Oracle Big Data Connectorsのみをアップグレードして、ソフトウェア・スタックの他のコンポーネントをアップグレードしない場合は、Oracle Supportにサポートを依頼してください。
ソフトウェアのダウングレードはサポートされません。
ノート:
mammoth
コマンドの実行中はクラスタを使用できません。
高可用性Sentryを含まないリリースからアップグレードする場合、SentryのHAを有効にするにはすべてのSentry依存サービスを短時間停止する必要があることを通知するメッセージがMammothにより表示されます。
現在、Oracle Big Data Applianceソフトウェアをアップグレードしても、対応するInfiniBandまたはCiscoスイッチのアップグレードは必要ありません。
10.7.1 オペレーティング・システムのバージョンについて
このOracle Big Data Applianceリリースでは、新規インストールでのOracle Linux 7、およびアップグレードでのOracle Linux 6がサポートされています。Oracle Linux 5はサポートされていません。
10.7.2 ソフトウェアのアップグレード
この項の手順に従って、Oracle Big Data Applianceクラスタのソフトウェアを現在のバージョンにアップグレードします。
リリース4.12、14.13、4.14からOracle Big Data Applianceリリース5.1に直接アップグレードできます。サポートされているClouderaのアップグレード・パスについては、Cloudera Enterprise Upgrade Guideを参照してください。
新しいCDHメジャー・リリースへのアップグレードは、Mammothの外部ではサポートされていません。これらはフルスタックのMammothアップグレードの一部として実行する必要があります。たとえば、CDH 5.13.1環境からCDH 6.0.1への手動アップグレードはサポートされていません。CDH 5.11リリースから5.12なども直接アップグレードできません。
同じメジャーリリース内の新しいメンテナンス・リリースへのマイナー(3番目の数字) CDHのアップグレードはサポートされています。たとえば、CDH 5.11を5.11.2に直接アップグレードできます。
ノート:
現在、Oracle Big Data Appliance 5.1では、ローリング・アップグレード(クラスタの停止時間が回避されます)はサポートされていません。Mammothによるアップグレードでは、クラスタの停止時間が必要となります。関連項目:
アップグレードの手順を実行する前に、アップグレードの既知の問題を確認してください10.7.2.1 アップグレード前のチェックリスト
ノート:
Oracle Big Data Applianceの外部にあるKey Trustee Serverを使用している場合は、Oracle Big Data Applianceをアップグレードする前に、外部Key Trustee Serverが構成されているサーバーをアップグレードする必要があります。Key Trustee Serverのアップグレード後、Oracle Big Data Applianceクラスタのアップグレードの前提条件となる手順を実行してから、アプライアンスをアップグレードできます。また、外部Key Trustee Serverから証明書をインポートする必要があります。これを行う手順は、次の手順に含まれています。
- クラスタで現在有効なパスワードのリストを取得します。Mammothから次のユーザーのパスワードの入力を求められます。
-
oracle
-
root
-
Cloudera Manager
admin
-
MySQL Database
admin
-
- Oracle Big Data Discoveryを無効にします。この製品は、Oracle Big Data Appliance 5.1ではサポートされません。アップグレードの実行時は、ODIエージェントが存在しないようにする必要があります。アップグレードする前にアンインストールします。
# bdacli disable bdd
- ODIエージェントをアンインストールします。このリリースのMammothによるインストールではODIエージェントはインストールされず、Mammothによるインストール後はbdacliを使用してエージェントをインストールできなくなります。
ODIエージェントには、別個のアンインストール手順はありません。削除するには、Oracle Big Data Connectorsをアンインストールしてから、エージェントなしでOracle Big Data Connectorsを再インストールします。どちらの操作でも、構成マネージャの管理パスワードと、MySQLルート・パスワードを使用して認証する必要があります。
# bdacli disable bdc
# bdacli enable bdc
Big Data Connectorsを有効にする場合は、次のプロンプトにnで応答してODIエージェントを除外します。Do you wish to enable ODI? [y/n]: n
Mammothのインストール後に、ODI製品のドキュメントの手順を使用して、スタンドアロンのODIエージェントのバージョン12.2.1.4を別途インストールできます。このバージョンのエージェントは、Cloudera 6互換として動作保証されています。
- アップグレードする前に、次のサービスを停止して削除します。これらは、Cloudera Enterprise 6の時点でサポートされなくなりました。
Accumulo Sqoop 2 MapReduce 1 Record Service
Spark 1.6もサポートされませんが、アップグレード中に自動的に削除されます。
Oracle Big Data Appliance 4.1では、Apache SentryはファイルベースのプロバイダからSentryサービスへ変更されました。クラスタをアップグレードするときにファイルベースのプロバイダとしてのSentryが有効であった場合、ファイルベースのプロバイダが維持されます。Sentryサービスへ切り替えるには、ソフトウェアをアップグレードする前にSentryを無効にし、後でSentryを再び有効にします。
- クラスタにSolrサービスがある場合は、そのSolrサービスに少なくとも1つのコレクションが存在することを確認します。それ以外の場合は、コレクションを追加するか、サービスを削除します。
- アップグレードの前にすべてのOozieジョブを停止してください。そうしないとアップグレードが失敗することがあります。
- 外部Key Trusteeサーバーを使用している場合は、アップグレードを開始する前に、次のように外部Key Trustee Serverの証明書をインポートする必要があります。
アクティブKey Trustee Serverの場合:
- Key Trustee証明書(
/opt/cloudera/security/x509/hostname.pem
)をアクティブKey Trustee ServerからMammothノード(Mammothが実行されるノード。通常はノード0)の/root
ディレクトリにコピーします。 - Mammothノードで、
keytool -importcert -file /root/hostname.pem -keystore /opt/cloudera/security/jks/<cluster_name>.truststore -alias keytrustee_active
を実行します。トラストストアへのフルパスを必ず含めてください。そうしないと、既存のトラストストアを変更するかわりに、新しいトラストストアが作成されます。
パッシブKey Trustee Serverの場合:- Key Trustee証明書(
/opt/cloudera/security/x509/hostname.pem
)をアクティブKey TrusteeサーバーからMammothノードの/root
ディレクトリにコピーします。 - Mammothノードで、
# keytool -importcert -file /root/hostname.pem -keystore /opt/cloudera/security/jks/<cluster_name>.truststore -alias keytrustee_passive
を実行します。トラストストアへのフルパスを必ず含めてください。そうしないと、既存のトラストストアを変更するかわりに、新しいトラストストアが作成されます。
- Mammothノードで、
# dcli -C -f /opt/cloudera/security/jks/<cluster_name>.truststore -d /opt/cloudera/security/jks
を実行します
- Key Trustee証明書(
- クラスタの同じノード内にKMSおよびHBaseのマスターの役割がある場合は、HBaseのマスターの役割を別のノードに移動する必要があります。KMSおよびHBaseのマスターの役割が同じノードにある場合、両方のロールが同じポート(16000)を使用しているため、アップグレード時にエラーが発生します。
- クラスタにBig Data SQLがインストールされていて、クラスタで(Oracle Linux 7ではなく) Oracle Linux 6が実行されている場合は、Python暗号化モジュールをインストールします(まだインストールされていない場合)。
Cloudera Managerが実行されるノード(通常はノード3)で、次のステップを実行します。
-
get-pip.py
スクリプトをダウンロードします。curl https://bootstrap.pypa.io/get-pip.py -o get-pip.py
- sclを使用してpipをインストールします。
scl enable python27 'python get-pip.py'
- Python暗号化モジュールをインストールします。
scl enable python27 'pip install cryptography'
ヒント:
モジュールがインストールされたことを確認するには、scl enable python27 'python -c "import cryptography"'
を実行してリターン・コードが0
であることを確認します。
-
10.7.2.2 アップグレードでのMammothのステップおよび範囲オプションの使用
いくつかのMammothインストーラ・オプションをアップグレードで使用することがサポートされています。
Mammothのステップ(-s
)および範囲(-r
)パラメータは、標準のmammoth -p
コマンドと組み合せて使用できるオプションです。
mammoth -s <n> -p
Mammothの指定されたアップグレード・ステップのみを実行します。
mammoth -r <n>-<n> -p
Mammothによるアップグレードのnからnの範囲のステップを実行します
これらのオプションが役に立つことがある状況の1つは、アップグレード作業に許されるメンテナンス・ウィンドウが、完全なアップグレードを実行するには不十分である可能性がある場合です。単一のアップグレード・ステップまたはステップの範囲を安全に完了し、後でアップグレードを再開できます。
次の表にアップグレードのステップを示します。該当するステップ番号の値をMammothのアップグレード・コマンドの-s
または-r
に指定します。
表10-1 アップグレードのステップ
ステップ | 説明 |
---|---|
1 |
アップグレードのための事前チェックおよび事前構成 |
2 |
オペレーティング・システムのアップグレード |
3および4 |
Cloudera Managerのアップグレード |
5 |
CDHのアップグレード |
6 |
Big Data Applianceソフトウェアのアップグレード |
7 |
Clouderaサービスの開始 |
8 |
Clouderaサービスの開始 |
例
- 事前チェックおよびOSのアップグレードのみを実行します。
# mammoth -r 1-2 -p
- Cloudera Managerのみをアップグレードします。
# mammoth -r 3-4 -p
- CDHのみをアップグレードします。
# mammoth -s 5 -p
- Clouderaサービスを開始します。
# mammoth -s 7 -p
- Big Data Managerをアップグレードして、最後のクリーン・アップを実行します。
# mammoth -s 8 -p
10.7.2.3 現在のソフトウェア・バージョンへのアップグレード
次のようにOracle Big Data Applianceソフトウェアを現在のソフトウェア・バージョンにアップグレードします。これはサマリーです。次のステップの詳細、既知の問題および前提条件は、My Oracle SupportのDoc ID 2101906を参照してください。
10.7.2.4 アップグレードの既知の問題
アップグレード中に発生する可能性があるエラーがあります。
Oracle Big Data DiscoveryまたはODI (Oracle Data Integrator)エージェントの無効化に失敗する
BDA version and Mammoth version are not the same: BDA-5.1.0 Mammoth-4.12.0
通常はbdacliコマンドを実行してこれらのコンポーネントを無効にしますが、この状況でそれを試行すると、次のエラー・メッセージのいずれかが返されます。
ERROR: Big Data Discovery is not supported for this BDA version.
ERROR: Oracle Data Integrator is not supported for this BDA version.
回避策は、以前のバージョンのMammothソフトウェアに一時的に戻し、bdacliを使用してOracle Big Data DiscoveryまたはODIエージェント(あるいはその両方)を無効にすることです。それが完了したら、新しくインストールしたMammothソフトウェアに切り替えます。これを行うことができるのは、以前のバージョンのMammothがアップグレードによって削除されないためです。以前のバージョンは、/opt/oracle/BDAMammoth/previous-BDAMammoth
に格納されています。
次の手順に従います。
- アップグレードによってインストールされた新しいOracle Big Data Appliance RPMをアンインストールします。次に例を示します。
# rpm -e bda-5.1.0-1.el6.x86_64
- アップグレードによって新しく作成された
BDAMammoth
ディレクトリをバックアップの場所に移動します。次に例を示します。# mv /opt/oracle/BDAMammoth/ /opt/oracle/BDAMammoth_v5
previous-BDAMammoth
ディレクトリ(Mammothによって作成されたバックアップ)をコピーして、/opt/oracle/BDAMammoth
に名前を変更します。# cp -pR /opt/oracle/BDAMammoth_v5/previous-BDAMammoth/ /opt/oracle/BDAMammoth
- ディレクトリを
/opt/oracle/BDAMammoth/bdarepo/RPMS/x86_64
に変更し、以前(アップグレード前)のOracle Big Data Appliance RPMを再インストールします。次に例を示します。# rpm -ivh bda-4.12.0-2.el7.x86_64.rpm
- Oracle Big Data DiscoveryまたはODIエージェントの無効化を再試行します。
# bdacli disable bdd
ノート:
ODIエージェントのみを無効にするbdacliコマンドはありません。Oracle Big Data Connectorsをアンインストールしてから、ODIエージェントなしで再インストールする必要があります。これを行うコマンドは、アップグレード前のチェックリストにあります - 削除に成功した場合は、新しいMammothソフトウェアに切り替えます。最初に、
/opt/oracle/BDAMammoth
の古いソフトウェアの一時的なインストールを削除してから、新しいディレクトリのアーカイブを/opt/oracle/BDAMammoth
に移動して名前を変更します。# rm -rf /opt/oracle/BDAMammoth
# mv /opt/oracle/BDAMammoth_v5 /opt/oracle/BDAMammoth
# mammmoth -p
同じノード上にHBaseおよびKerberos Key Management Serverがある場合にエラーがレポートされる
アップグレード前のチェックリストで説明したように、CDH 6、KMSおよびHBaseはデフォルトでポート16000を使用します。このため、同じノードで両方を実行している場合、アップグレード中に「Address already in use
」というエラーが発生します。このエラーは、Cloudera Manager管理コンソールに表示できます。コンソールで、実行中のコマンドの番号を示すインジケータをクリックします。「All Recent Commands」をクリックし、Upgrade Cluster
コマンドの最新の実行を見つけます。
java.lang.RuntimeException: Failed construction of Master
Caused by: org.apache.hbase.thirdparty.io.netty.channel.unix.Errors$NativeIoException: bind(..) failed: Address already in use
このエラーを修正するには、HBaseマスターのポートを変更します。構成マネージャで、「HBase」→「configuration」
に移動し、hbase.master.port
の値を変更します。割り当てるポート番号がまだ使用されていないことを確認します。
この競合を解決した後にアップグレードを続行するには、mammoth -p
を実行します。
クラスタにSolrがすでにインストールされている場合に、アップグレードのステップ5 (CDHのアップグレード)で予期されているエラー
アップグレード前のシステムにCDH 5 Solr以前が存在する場合は、このエラーが必ず発生します。
ERROR: This is an expected error.
The Apache Solr version in Cloudera Search in CDH 5 is incompatible with the Solr version in CDH 6.
Please, follow the documentation to fix this issue before continue with the upgrade.
このエラー・メッセージでは、Clouderaのドキュメントについて言及されています。Migrating Cloudera Search Configuration Before Upgrading to CDH 6を参照してください。Clouderaの手順が完了したら、mammoth -p
を実行して続行します。
ステップ5でYARN ResourceManagerの起動時にエラーが発生する
Error starting ResourceManager
org.apache.hadoop.service.ServiceStateException: org.apache.zookeeper.KeeperException$NoAuthException:
KeeperErrorCode = NoAuth for /yarn-leader-election/yarnRM/ActiveStandbyElectorLock
この問題を修正するには、ZooKeeperで/yarn-leader-election
および/rmstore/ZKRMStateRoot
を削除します。
これを行うには、ZooKeeperにsuper-auth
キーを追加します。Javaを使用してダイジェストを取得し、それを使用して構成マネージャのZooKeeper構成オプション内にスーパーユーザーを一時的に定義できます。そのスーパーユーザーを使用して、/yarn-leader-election
および/rmstore/ZKRMStateRoot
を削除できます。
- 最初に、次のコマンドを実行し、選択したパスワードを使用してZooKeeperのスーパーユーザーを有効にするために必要なダイジェストを取得します。
java -classpath zookeeper.jar:lib/* org.apache.zookeeper.server.auth.DigestAuthenticationProvider super:cloudera
コマンドによってダイジェストが返されます。次に例を示します。
super:cloudera->super:cY+9eK20soteVC3fQ83SXDvwlP0=
- 構成マネージャで、
「Zookeeper service configuration」→「Java Configuration Options for ZooKeeper Server」
に移動します。 - 次の文字列を構成オプションに追加します。重要: 既存のオプションを上書きしないようにしてください。
-Dzookeeper.DigestAuthenticationProvider.superDigest=<The required digest>
たとえば、最初のステップで返されたダイジェストを使用すると、次のようになります。
-Dzookeeper.DigestAuthenticationProvider.superDigest=super:cY+9eK20soteVC3fQ83SXDvwlP0=
- 変更内容を保存して、ZooKeeperサービスを再起動します。
- ZooKeeperクライアントを使用して、Hadoopノードの1つにSSHで接続し、次の3つのコマンドを実行します。
zookeeper-client -server zk_host:2181 addauth digest super:cloudera rmr /yarn-leader-election rmr /rmstore/ZKRMStateRoot
- YARNサービスを再起動します。
「Zookeeper service configuration」→「Java Configuration Options for ZooKeeper Server」
から-Dzookeeper.DigestAuthenticationProvider.superDigest
を削除します。- 変更内容を保存して、ZooKeeperサービスを再起動します。
- アップグレードを再開します。
# mammoth -p
ヒント:
これらの手順では、mammoth -p
を使用してアップグレードを再開するように一貫して指示しています。必要に応じて、構成マネージャを使用してアップグレードを再開することもできます(CMで、「All recent commands」に移動し、「Upgrade CDH Cluster」を見つけて、「Resume」オプションをクリックします)。これらの方法は同等ですが、mammoth -p
を使用すると、発生する可能性のあるエラーがより迅速に表示されます。
ノードの再起動後にBigDataSQLの状態が不正であると構成マネージャに表示される
この問題は、アップグレード前にOracle Big Data SQLがすでにインストールされていた場合に必ず発生します。アップグレード時に各ノードが再起動されると、Cloudera Configuration ManagerにBigDataSQLサービスの状態が不正であることが示されます。これは予期されており、JAVA_HOMEが変更された場合にのみ発生します。後でアップグレード処理で修正が行われ、BigDataSQLは正常な状態にリストアされます。場合によっては、自動リストアで正常な状態に回復されるまで待てないことがあります。たとえば、複数のメンテナンス・ウィンドウでアップグレードを実行する場合です。Big Data SQLのJaguarユーティリティを使用すると、BigDataSQLサービスを正常な状態に手動でリストアできます。Jaguarのreconfigure
操作によって問題が修正されます。
# ./jaguar reconfigure <myconfigfilename>.json
デフォルトのパスおよび構成ファイルは、/opt/oracle/BDSjaguar/bds-config.json
です。ただし、Big Data SQLをインストールした担当者が、別のパスを設定して別のファイル名を使用した可能性があります。BDSjaguar
ディレクトリを探します。構成ファイルはそこにあります。サービスの状態の問題を修正するために構成ファイルを変更する必要はありません。
10.7.2.5 アップグレード後の既知の問題
アップグレード後に、次の問題が発生することがあります。
必要なPsycopg2バージョンに関する警告
Warning: Starting with CDH 6, PostgreSQL-backed Hue requires Psycopg2 version to be at least 2.5.4
これは予期されている警告です。Big Data ApplianceクラスタではPostgreSQLではなくMySQLデータベースが使用されるため、この警告は無視できます。
10.7.2.6 個別パッチ・メカニズムを使用しないパーセルのアップグレードの実行
当然のことながら、Oracle Big Data Applianceソフトウェア用のOracleの個別パッチはサポートされています。 個別パッチの一環として行われないパーセルのアップグレードは、Oracleサポートの承認がないかぎり、サポートされません。
Mammothバンドルには、Cloudera's Distribution including Apache Hadoop (CDH)のパーセルの最新のバージョンが含まれています。ただし、CDHはClouderaのスケジュールに合わせてリリースされており、現在のMammothバンドルよりも新しいCDHのリリースが利用できる場合があります。新しいバージョンのCDHが、現在のOracle Big Data Applianceリリースとの統合のためにサポートされている可能性があります。疑問がある場合は、Oracleサポートに問い合せてください。
10.8 Oracle Linux 6からOracle Linux 7への移行
既存のOracle Linux 6クラスタをX7-2Lサーバーで拡張する場合は、Oracle Linux 7にクラスタをアップグレードすることを検討してください。これらの最新の2つのサーバー・モデルは、Oracle Linux 7がインストールされて出荷されます。Oracle Linux 6クラスタはOracle Linux 7ノードをサポートしません。
このアップグレードはCDHクラスタ専用です。Oracle NoSQL Databaseクラスタには適用されません。
クラスタは、Oracle Linux 7への移行を開始する前に、Oracle Big Data Appliance 5.1である必要があります
このリリースでのオペレーティング・システムの移行には2つのパッチが必要となります
- パッチ30459890: ORACLE BIG DATA APPLIANCE MAMMOTHデプロイメント・バンドルV5.1.0 FOR ORACLE LINUX 7
- 最新のOracle Big Data Applianceベース・イメージ(v4.10.0-11以降) for Oracle Linux 7。このイメージには、Oracle Linux 6からOracle Linux 7への移行のサポートが含まれています。
https://support.oracle.com/epmos/faces/PatchDetail?patchId=28218768
移行に必要な時間の見積り
クラスタ全体のOracle Big Data Appliance Mammothアップグレードを実行してから、ノードごとにOSを移行する時間の合計が長くなる可能性があります。主な要因は、クラスタのサイズと、ノードのサーバー・モデルです。
スレーブ・ノードの場合、移行には3時間から4時間かかる場合があります。マスター・ノードの場合、MySQLデータベースのサイズ次第で、プロセスに5時間以上かかる場合もあります。
複数のノードの同時移行について
一度に複数のクリティカル・ノードを移行することはできません。(クリティカル・ノードはノード0からノード3です)。
この制約を使用して、クリティカルでない2つのノードを同時に移行することは可能です(3つ以上は不可)。
- 移行されるノードの最初のペアについては、最初のノードで
bdarestorenode.sh
の実行を完了してから、2番目のノードでbdarestorenode.sh
の実行を開始する必要があります。
一般的に、クラスタ内でbdarestorenode.sh
を同時に複数回実行しないことをお薦めします。ただし、bdadumpnode.sh
、bdareimagenode.sh
を実行し、プロセス内の他のステップを2つの非クリティカル・ノードに対して同時に実行することはできます。
ノート:
移行の進行中、一部のノードはOracle Linux 7で実行され、その他のノードはOracle Linux 6で引き続き実行されます。この期間はクラスタの使用を継続しても安全です。ただし、アップグレードの進行中は、新しいサービスをクラスタに追加しないでください。
10.8.1 重要な考慮事項
アップグレードを開始する前に知っておく必要がある事項を次に示します。
OSアップグレードでは最新のOracle Big Data Applianceベース・イメージが使用される
Oracle Linux 7の最新のOracle Big Data Applianceベース・イメージ(4.10.0-12以上)を、各ノードに直接ダウンロードするか、各ノードにイメージをコピーできるクラスタ内の場所にダウンロードする必要があります。この手順では、各ノードにベース・イメージを解凍しますが、インストールしないでください。OSのアップグレードでは、ベース・イメージで使用可能な機能の一部を利用します。
Mammothでインストールされたソフトウェアのみ移行される
OSアップグレード・プロセスではバックアップが実行されず、Big Data Applianceのインストール・ユーティリティであるMammothによってインストールされなかったソフトウェアは移行されません。
Mammothインストール・メカニズム以外のサード・パーティ・ソフトウェア製品をインストールしている場合は、アップグレード後に、バックアップとリストア、またはそれらのソフトウェアの再インストールを個別に準備する必要があります。これには、MammothによってインストールされないOracleソフトウェアと、Clouderaソフトウェア(KuduやKafkaなど、便宜上Mammothソフトウェア・デプロイメント・バンドルに含めることができるが、Mammothによってインストールされないソフトウェア)が含まれます。
また、ユーザーによってOracle Linux 6カーネルに追加されるOracle Linuxモジュールは、Oracle Linux 7インストールに移行されません。
各ノードで、Mammothによってインストールされていないロールをノードのアップグレード前に削除する必要がある
各ノードでアップグレードを開始する前に、Cloudera Managerを使用して、ノードで実行中のロールを見つけます。Mammothによってインストールされていないすべてのロールを必ず削除してください。そうしないと、アップグレードが失敗する可能性があります。
ファイルのバックアップに関する考慮事項
このプロセスでは、バックアップする重要なファイルのリストが生成されます。独自のリストを追加することもできます。
HDFSデータはアップグレードで維持されます。
移行の前に保存する必要のある非HDFSデータを個別にバックアップするのはお客様の責任です。HDFSに格納されていないすべてのファイルをバックアップすることをお薦めします。
アップグレード中のサービスの中断
重要なノード(一般にはノード1 - 4)のアップグレードでは、重要なサービスを必ず一時的に中断する必要がありますが、どの時点でもクラスタ全体がシャットダウンされることはありません。進行中のジョブは引き続き実行できます。Hadoop機能は部分的に残されるか、大部分を使用できます。プロセスのどの時点でサービスが停止されるかは、現在アップグレードを実行中のノードで実行されているサービスとロールによって異なります。
Oracle Big Data Applianceでのデータの3要素レプリケーションにより、重要性の低いノード(主にデータを格納するノード)のアップグレード中に、サービスが失われることはありません。クラスタでレプリケーション係数が3 (デフォルト)に設定されていることを確認します。そうでない場合は、アップグレードを実行中のノードのデータを一時的に使用できなくなる場合があります。
1ラック・クラスタとマルチラック・クラスタのノード全体のサービスとロールの分散には、いくつかの違いがあります。ノードでアップグレードを実行中に、ノードで実行中のサービスを使用できない場合は、クラスタのノードでアップグレードをどのように指定し、スケジュール設定しているかに原因がある可能性があります。これ以外は、1ラック・クラスタとマルチラック・クラスタのアップグレード・プロセスで特別な考慮事項はありません。
セキュリティ設定は維持される
Kerberosセキュリティ構成とHDFS透過的暗号化およびHTTPS/ネットワーク暗号化はアップグレードで保持されます。
Cloudera Managerのロールはアップグレードで維持されます。
MySQLデータベースは保持される
各ノードのアップグレード・ステップで、bdadumpnode.sh
スクリプトを実行してノードに関する情報を保持します。MySQLデータベースが実行されるノード(通常はNode3)に、MySQLデータベースのダンプが含まれます。データベースの追加ダンプを実行する場合は、Node3でアップグレードを開始する直前に実行します。手動ダンプのデータベース状態が、アップグレードにより実行される自動ダンプと一致していることを確認してください。手動ダンプは別のノードの別の場所に格納します。
各ノードのアップグレード後にヘルス・チェックを実行し、必要に応じて負荷をリバランス
各ノードでアップグレードが完了した後、クラスタ状態を再チェックし(mammoth -c
)、Cloudera Manager Webコンソールを使用してサービスのヘルス・ステータスを再チェックします。
OSアップグレード中、アップグレードされているノードのHDFSデータは他のノードに自動的にレプリケートされます。レプリケートされたデータを受け取るノードの負荷がすでに高い場合、CMでは、レプリケーションが一部のDataNodeロールに対して心配な状態であることを示す黄色のインジケータをトリガーすることがあります。
この状況が発生した場合、次のアップグレードに進む前にCMでHDFS Balancerを実行してください。黄色の警告インジケータの原因が過度の利用である場合は、リバランスによってその原因を消去する必要があります。
-
構成マネージャで、HDFSサービスに移動します。
-
「Actions」を選択した後、「Rebalance」を選択します。
-
「Rebalance」をクリックして続行します。
ノート:
データ・ボリュームによっては、リバランスに長時間かかる場合があります。Oracle Big Data Connectorsを有効にすると、アップグレード後にORAAHが機能しないことがある
これを解決するには、アップグレード後にOracle Big Data Connectorsを無効にしてから再度有効にします。どちらの操作でも、構成マネージャの管理パスワードと、MySQLルート・パスワードを使用して認証する必要があります。
# bdacli disable bdc
# bdcali enable bdc
Big Data Connectorsを再度有効にする場合、Big Data Appliance 5.1はODIエージェントをサポートしないことに注意してください。次のプロンプトで、nを入力します。
Do you wish to enable ODI? [y/n]: n
ノードのイメージ変更中に発生するエラー
bdareimagenode: Preparing internal USB disk failed
このエラーが表示された場合は、次のようにします。
- ノードを再起動します。
-
lsscsi
を実行し、ディスクが正しい順序であることを確認します。 mount -l
を実行して、マウント済のHDFSパーティションを確認します。異常がないかどうか確認します。- ノードのイメージ変更を繰り返します。
# ./bdareimagenode.sh | tee /path_to_log/bdareimagenode.log
cp: writing `/tmp/bdausbmnt/boot/upgrade.img': No space left on device
4 GBのUSBドライブでサーバーをイメージ変更する場合、このエラーはログ・ファイル
bdareimagenode-prepare-usb.out
に記録されます。これは予想範囲のエラーで問題はないため、無視できます。upgrade.img
ファイルおよびそれ以降のすべてのファイルは、イメージ変更処理によって不要となります。
10.8.2 Oracle Linux 7への移行の前提条件
移行に進む前に、これらの前提条件が満たされていることを確認してください。
- クラスタのソフトウェア・レベルは、Oracle Big Data Appliance 4.13.0以上ではOracle Linux 6である必要がある
-
Oracle Big Data SQLの無効化またはアンインストール
Oracle Big Data SQLがインストールされている場合、ノードでOSアップグレードを実行する前に、インストールのHadoop側をアンインストールする必要があります。インストールのデータベース・サーバー側をアンインストールする必要はありません。HadoopクラスタでOSアップグレード中にデータベース側は影響を受けませんが、アップグレードの進行中、Big Data SQLクラスタを再度有効にするまでは、Hadoopのデータに対する問合せは機能しません。
-
Oracle Big Data SQL 3.2以降の場合は、次のbdacliコマンドを使用して、クラスタ全体でこのOracle Big Data SQLを無効にします。
# bdacli disable big_data_sql
-
以前のバージョンのOracle Big Data SQLがインストールされている場合は、uninstallパラメータ、およびインストールの実行に使用した構成ファイルと同じバージョンの構成ファイルを指定した
setup-bds
コマンドを使用します。# ./setup-bds uninstall bds-config.json
ヒント:
使用する方法がわからない場合、安全なのはbdacli disable big_data_sql
を試行することです。このコマンドが失敗した場合、./setup-bds
を使用してソフトウェアがインストールされた可能性があります。OSアップグレードの前に、Oracle Big Data SQLを削除していない場合、Oracle Big Data SQLを削除する必要がある旨のメッセージがプロセスで表示され、エラーで終了します。
アップグレード後に、Big Data SQLをHadoopクラスタに再インストールし、インストールのデータベース側と再接続します。HadoopクラスタにOracle Big Data SQLを再インストールした後に接続の問題が発生した場合は、データベース・サーバーでインストールの再構成を試み、2つの側を再度整合させることができます。『Oracle Big Data SQLインストレーション・ガイド』の
./bds-database-install.sh --reconfigure
に関する項を参照してください。 -
-
eCryptfsが使用されている場合はアンインストールする
古いバージョンのOracle Big DataではeCryptfsの使用がサポートされていましたが、この暗号化メソッドのサポートは後続のバージョンで非推奨になりました。eCryptfs暗号化を使用するノードのアップグレードはサポートされていません。
eCryptfsを削除していない場合、OSをアップグレードすると、それらを削除する必要がある旨のメッセージが表示され、エラーで終了します
移行の前または後に、HDFS透過的暗号化を使用してデータを再暗号化できます。
HDFS透過的暗号化およびHTTPS/ネットワーク暗号化はOSアップグレードの影響を受けません。
10.8.3 Oracle Linux 6からOracle Linux 7への移行ステップ
これはクラスタをOracle Linux 6からOracle Linux 7にアップグレードする手順です。
再起動ステップの前に別のノードに重要な情報を保存するための要件には特に注意してください。
10.8.4 Oracle Linux 6からOracle Linux 7への移行での出力例
次の例は、Oracle Linux 7への移行時に実行する操作で予想される出力を示しています。これらの例とご使用のシステムで表示される出力には、多少違いがある場合があります。
bdadumpnode.sh
# ./bdadumpnode.sh
bdadumpnode: working directory : /root/BDABaseImage-ol7-4.10.0_190314
Enter CM admin password:
Enter CM admin password again:
bdadumpnode: CM REST API version : v19
Enter MySQL root password:
Enter MySQL root password again:
bdadumpnode: required disk space(1K blocks) : 18163
bdadumpnode: Backup directory selected : /u01/osupgrade_backup
bdadumpnode: HDFS Transparent Encryption is enabled on this cluster
bdadumpnode: Stopping all hadoop roles on host : <node name>13
bdadumpnode: Succeeded. Output in : /opt/oracle/BDAMammoth/bdaconfig/tmp/cm_commands.out
bdadumpnode: Succeeded. Output in : /opt/oracle/BDAMammoth/bdaconfig/tmp/hosts_7634f839-f511-44d7-b2dd-a9991230291b_view_full_1552690645.out
bdadumpnode: Stopping yarn - yarn-NODEMANAGER-2bb159eb8269eec214d88ac80364bf9a
bdadumpnode: Succeeded. Output in : /opt/oracle/BDAMammoth/bdaconfig/tmp/clusters_scajvm_services_yarn_roleCommands_stop_1552690646.out
bdadumpnode: Command 1613 finished after 5 seconds
bdadumpnode: Operation completed successfully
bdadumpnode: Stopping hdfs - hdfs-DATANODE-2bb159eb8269eec214d88ac80364bf9a
bdadumpnode: Succeeded. Output in : /opt/oracle/BDAMammoth/bdaconfig/tmp/clusters_scajvm_services_hdfs_roleCommands_stop_1552690654.out
bdadumpnode: Command 1616 finished after 5 seconds
bdadumpnode: Operation completed successfully
bdadumpnode: Stopping Cloudera Manager Agent and Server on host : <node name>13
Stopping cloudera-scm-agent: [60G[[0;32m OK [0;39m]
bdadumpnode: Backing up files on host : <node name>13
bdadumpnode: Copying : /etc/auto_direct_bda
bdadumpnode: Copying : /etc/auto.master
bdadumpnode: Copying : /etc/cloudera-scm-agent
bdadumpnode: Copying : /etc/cloudera-scm-server
bdadumpnode: Copying : /etc/dnsmasq.conf
bdadumpnode: Copying : /etc/exports
bdadumpnode: Copying : /etc/group
bdadumpnode: Copying : /etc/hosts
bdadumpnode: Copying : /etc/my.cnf
bdadumpnode: Copying : /etc/passwd
bdadumpnode: Copying : /etc/puppet
bdadumpnode: Copying : /etc/resolv.conf
bdadumpnode: Copying : /etc/shadow
bdadumpnode: Copying : /etc/ssh
bdadumpnode: Copying : /etc/yum.conf
bdadumpnode: Copying : /etc/yum.repos.d/bda.repo
bdadumpnode: Copying : /home
bdadumpnode: Copying : /opt/cloudera/csd
bdadumpnode: Copying : /opt/cloudera/security
bdadumpnode: Copying : /opt/exportdir
bdadumpnode: Copying : /opt/hadoop
bdadumpnode: Copying : /opt/oracle/bda/bin/krb5prop.sh
bdadumpnode: Copying : /opt/oracle/bda/cluster-hosts-infiniband
bdadumpnode: Copying : /opt/oracle/bda/.imagehistory
bdadumpnode: Copying : /opt/oracle/bda/install/log
bdadumpnode: Copying : /opt/oracle/bda/install/state
bdadumpnode: Copying : /opt/oracle.cellos
bdadumpnode: Copying : /opt/oracle.ExaWatcher
bdadumpnode: Copying : /opt/oracle/odiagent
bdadumpnode: Copying : /opt/oracle.oswatcher
bdadumpnode: Copying : /opt/oracle/oxh-4.9.1-1.cdh5.0.0
bdadumpnode: Copying : /root/.ssh
bdadumpnode: Copying : /usr/java/default/jre/lib/security/local_policy.jar
bdadumpnode: Copying : /usr/share/java/mysql-connector-java-commercial-5.1.34-bin.jar
bdadumpnode: Copying : /usr/share/java/mysql-connector-java.jar
bdadumpnode: Copying : /var/lib/cloudera-scm-agent
bdadumpnode: Copying : /var/lib/cloudera-scm-navigator
bdadumpnode: Copying : /var/lib/cloudera-scm-server
bdadumpnode: Copying : /var/lib/oozie
bdadumpnode: Copying : /var/lib/puppet
bdadumpnode: Copying : /var/lib/zookeeper
****************************************************
bdadumpnode: Node dump completed successfully on host : <node name>13
****************************************************
bdareimagenode.sh
# ./bdareimagenode.sh
bdareimagenode: Using BDABaseImage-ol7-4.10.0_190314.iso to reimage this node
BDABaseImage-ol7-4.10.0_190314.iso: OK
bdareimagenode: Using node nr : 13
bdareimagenode: Using network files: /opt/oracle/bda/rack-network.json & /opt/oracle/bda/cluster-network.json
bdareimagenode: Running makebdaimage...
bdareimagenode: Resetting disk labels of data partitions to DO_NOT_WIPE on specified servers
hba slot: s0p4
hba slot: s1p4
hba slot: s2p1
hba slot: s3p1
hba slot: s4p1
hba slot: s5p1
hba slot: s6p1
hba slot: s7p1
hba slot: s8p1
hba slot: s9p1
hba slot: s10p1
hba slot: s11p1
bdareimagenode: Internal USB disk has been prepared. All disk labels have been set to DO_NOT_WIPE
bdareimagenode: Please check log /tmp/bdareimagenode-prepare-usb.out. If no error then reboot this server
bdarestorenode.sh
# ./bdarestorenode.sh
bdarestorenode: working directory : /root
Enter CM admin password:
Enter CM admin password again:
bdarestorenode: CM REST API version : v19
bdarestorenode: restoring systhem data on host : <node name>13
bdarestorenode: working directory : /u01/osupgrade_backup
bdarestorenode: merging passwd, shadow and group
bdarestorenode: restoring /etc directories
bdarestorenode: restoring /var/lib directories
bdarestorenode: restoring /opt directories
bdarestorenode: restoring puppet, ssh, jce, and mysql java directories
bdarestorenode: adding domain to /etc/idmapd.conf
Loaded plugins: langpacks
=============================== repo: ol7_UEKR4 ================================
[ol7_UEKR4]
async = True
bandwidth = 0
base_persistdir = /var/lib/yum/repos/x86_64/7Server
baseurl = https://yum.oracle.com/repo/OracleLinux/OL7/UEKR4/x86_64/
cache = 0
cachedir = /var/cache/yum/x86_64/7Server/ol7_UEKR4
check_config_file_age = True
compare_providers_priority = 80
cost = 1000
deltarpm_metadata_percentage = 100
deltarpm_percentage =
enabled = 0
enablegroups = True
exclude =
failovermethod = priority
ftp_disable_epsv = False
gpgcadir = /var/lib/yum/repos/x86_64/7Server/ol7_UEKR4/gpgcadir
gpgcakey =
gpgcheck = True
gpgdir = /var/lib/yum/repos/x86_64/7Server/ol7_UEKR4/gpgdir
gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-oracle
hdrdir = /var/cache/yum/x86_64/7Server/ol7_UEKR4/headers
http_caching = all
includepkgs =
ip_resolve =
keepalive = True
keepcache = False
mddownloadpolicy = sqlite
mdpolicy = group:small
mediaid =
metadata_expire = 21600
metadata_expire_filter = read-only:present
metalink =
minrate = 0
mirrorlist =
mirrorlist_expire = 86400
name = Latest Unbreakable Enterprise Kernel Release 4 for Oracle Linux 7Server (x86_64)
old_base_cache_dir =
password =
persistdir = /var/lib/yum/repos/x86_64/7Server/ol7_UEKR4
pkgdir = /var/cache/yum/x86_64/7Server/ol7_UEKR4/packages
proxy = False
proxy_dict =
proxy_password =
proxy_username =
repo_gpgcheck = False
retries = 10
skip_if_unavailable = False
ssl_check_cert_permissions = True
sslcacert =
sslclientcert =
sslclientkey =
sslverify = True
throttle = 0
timeout = 30.0
ui_id = ol7_UEKR4/x86_64
ui_repoid_vars = releasever,
basearch
username =
=============================== repo: ol7_latest ===============================
[ol7_latest]
async = True
bandwidth = 0
base_persistdir = /var/lib/yum/repos/x86_64/7Server
baseurl = https://yum.oracle.com/repo/OracleLinux/OL7/latest/x86_64/
cache = 0
cachedir = /var/cache/yum/x86_64/7Server/ol7_latest
check_config_file_age = True
compare_providers_priority = 80
cost = 1000
deltarpm_metadata_percentage = 100
deltarpm_percentage =
enabled = 0
enablegroups = True
exclude =
failovermethod = priority
ftp_disable_epsv = False
gpgcadir = /var/lib/yum/repos/x86_64/7Server/ol7_latest/gpgcadir
gpgcakey =
gpgcheck = True
gpgdir = /var/lib/yum/repos/x86_64/7Server/ol7_latest/gpgdir
gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-oracle
hdrdir = /var/cache/yum/x86_64/7Server/ol7_latest/headers
http_caching = all
includepkgs =
ip_resolve =
keepalive = True
keepcache = False
mddownloadpolicy = sqlite
mdpolicy = group:small
mediaid =
metadata_expire = 21600
metadata_expire_filter = read-only:present
metalink =
minrate = 0
mirrorlist =
mirrorlist_expire = 86400
name = Oracle Linux 7Server Latest (x86_64)
old_base_cache_dir =
password =
persistdir = /var/lib/yum/repos/x86_64/7Server/ol7_latest
pkgdir = /var/cache/yum/x86_64/7Server/ol7_latest/packages
proxy = False
proxy_dict =
proxy_password =
proxy_username =
repo_gpgcheck = False
retries = 10
skip_if_unavailable = False
ssl_check_cert_permissions = True
sslcacert =
sslclientcert =
sslclientkey =
sslverify = True
throttle = 0
timeout = 30.0
ui_id = ol7_latest/x86_64
ui_repoid_vars = releasever,
basearch
username =
Unpacking JAR files...
tools.jar...
plugin.jar...
javaws.jar...
deploy.jar...
rt.jar...
jsse.jar...
charsets.jar...
localedata.jar...
bdarestorenode: checking ol7 bundle directory on node : <node name>09
bdarestorenode: Ensure CDH ol7 parcel in the remote temp repo
bdarestorenode: Ensure Cloudera Manager ol7 pkgs in the bdarepo
bdarestorenode: Ensure MySQL ol7 pkgs in the bdarepo
Loaded plugins: langpacks, ulninfo
Cleaning repos: bda
Cleaning up everything
Maybe you want: rm -rf /var/cache/yum, to also free up space taken by orphaned data from disabled or removed repos
Loaded plugins: aliases, changelog, filter-data, keys, list-data, ps, security,
: verify
Cleaning repos: bda
Cleaning up Everything
Could not find valid repo at: /var/www/html/bda
Spawning worker 0 with 1528 pkgs
Workers Finished
Gathering worker results
Saving Primary metadata
Saving file lists metadata
Saving other metadata
Generating sqlite DBs
Sqlite DBs complete
bdarestorenode: restoring Kerberos directories
bdarestorenode: installing MySQL ol7 pkgs on host : <node name>13
bdarestorenode: restoring my.cnf
bdarestorenode: installing cloudera manager pkgs
bdarestorenode: restoring cloudera directories
bdarestorenode: starting cloudera manager services
Starting cloudera-scm-agent (via systemctl): [60G[[0;32m OK [0;39m]
bdarestorenode: waiting for CDH parcel to automatically deploy on node : <node name>13
bdarestorenode: Succeeded. Output in : /opt/oracle/BDAMammoth/bdaconfig/tmp/cm_commands.out
bdarestorenode: Succeeded. Output in : /opt/oracle/BDAMammoth/bdaconfig/tmp/cm_config_1552708777.out
bdarestorenode: Succeeded. Output in : /opt/oracle/BDAMammoth/bdaconfig/tmp/clusters_scajvm_parcels_products_CDH_versions_5.15.1-1.cdh5.15.1.p0.4_1552708957.out
bdarestorenode: Succeeded. Output in : /opt/oracle/BDAMammoth/bdaconfig/tmp/clusters_scajvm_parcels_products_CDH_versions_5.15.1-1.cdh5.15.1.p0.4_1552709018.out
bdarestorenode: Succeeded. Output in : /opt/oracle/BDAMammoth/bdaconfig/tmp/clusters_scajvm_parcels_products_CDH_versions_5.15.1-1.cdh5.15.1.p0.4_1552709079.out
bdarestorenode: Succeeded. Output in : /opt/oracle/BDAMammoth/bdaconfig/tmp/clusters_scajvm_parcels_products_CDH_versions_5.15.1-1.cdh5.15.1.p0.4_1552709139.out
bdarestorenode: Succeeded. Output in : /opt/oracle/BDAMammoth/bdaconfig/tmp/clusters_scajvm_parcels_products_CDH_versions_5.15.1-1.cdh5.15.1.p0.4_1552709200.out
bdarestorenode: Succeeded. Output in : /opt/oracle/BDAMammoth/bdaconfig/tmp/clusters_scajvm_parcels_products_CDH_versions_5.15.1-1.cdh5.15.1.p0.4_1552709261.out
bdarestorenode: Succeeded. Output in : /opt/oracle/BDAMammoth/bdaconfig/tmp/clusters_scajvm_parcels_products_CDH_versions_5.15.1-1.cdh5.15.1.p0.4_1552709322.out
bdarestorenode: CDH parcel activated successfully! : CDH-5.15.1-1.cdh5.15.1.p0.4-el7.parcel
bdarestorenode: waiting for SPARK2 parcel to automatically deploy on node : <node name>13
bdarestorenode: Succeeded. Output in : /opt/oracle/BDAMammoth/bdaconfig/tmp/clusters_scajvm_parcels_products_SPARK2_versions_2.3.0.cloudera3-1.cdh5.13.3.p0.458809_1552709325.out
bdarestorenode: Spark2 parcel activated successfully! : SPARK2-2.3.0.cloudera3-1.cdh5.13.3.p0.458809-el7.parcel
bdarestorenode: Succeeded. Output in : /opt/oracle/BDAMammoth/bdaconfig/tmp/clusters_scajvm_parcels_products_KEYTRUSTEE_SERVER_versions_5.15.0-1.keytrustee5.15.0.p0.278282_1552709329.out
bdarestorenode: Succeeded. Output in : /opt/oracle/BDAMammoth/bdaconfig/tmp/clusters_scajvm_parcels_products_KEYTRUSTEE_SERVER_versions_5.15.0-1.keytrustee5.15.0.p0.278282_1552709389.out
bdarestorenode: Succeeded. Output in : /opt/oracle/BDAMammoth/bdaconfig/tmp/clusters_scajvm_parcels_products_KEYTRUSTEE_SERVER_versions_5.15.0-1.keytrustee5.15.0.p0.278282_1552709450.out
bdarestorenode: Key Trustee Server parcel activated successfully! : 5.15.0-1.keytrustee5.15.0.p0.278282
bdarestorenode: Succeeded. Output in : /opt/oracle/BDAMammoth/bdaconfig/tmp/clusters_scajvm_parcels_products_KEYTRUSTEE_versions_5.15.1-1.KEYTRUSTEE5.15.1.p0.484462_1552709453.out
bdarestorenode: KeyTrustee parcel activated successfully! : KEYTRUSTEE-5.15.1-1.KEYTRUSTEE5.15.1.p0.484462-el7.parcel
bdarestorenode: start_hadoop_roles_in_current_host
bdarestorenode: Succeeded. Output in : /opt/oracle/BDAMammoth/bdaconfig/tmp/cm_commands.out
bdarestorenode: Succeeded. Output in : /opt/oracle/BDAMammoth/bdaconfig/tmp/cm_commands_hostsStartRoles.out
.......bdarestorenode: Command 1621 finished after 40 seconds
bdarestorenode: Operation completed successfully
bdarestorenode: Installing OSG
bdarestorenode: Installing Oracle R and ORAAH : <node name>13
bdarestorenode: Installing Oraloader
bdarestorenode: Installing Oxh
bdarestorenode: /u01/osupgrade_backup/my_filelist not found. No customer data to restore
*****************************************************
bdarestorenode: OS upgrade completed successfully on host : <node name>13
*****************************************************
10.9 このリリースに付属のオプション・ソフトウェアの有効化
Oracle Big Data Applianceには、オプションの多数のソフトウェア・パッケージが含まれています。初期インストールでこれらのパッケージをインストールするよう選択しなかった場合は、後でそれらの決定の一部を元に戻すことができます。場合によっては、bdacli
ユーティリティを使用してオプションのソフトウェアをすばやく有効にできます。それ以外の場合は、さらに設定と構成のステップが必要です。必要な場合は、関連するサーバー名、ポート、ユーザー名およびパスワードを指定する準備をします。
この項では、再構成オプションの例をいくつか示します。
ノート:
構文の詳細は、「bdacli」を参照してください。
10.9.1 Oracle Big Data Connectorsの有効化または無効化
Oracle Big Data Connectorsは、Oracle Big Data Applianceデプロイメント・バンドルに含まれています。Oracle Big Data Applianceのユーザーは、外部ソースからOracle Big Data Connectorsをダウンロードする必要はありません。ただし、新しいバージョンをこのリリースのOracle Big Data Applianceで使用することが承認されている場合は、新しいバージョンをダウンロードしてインストールできます。
Oracle Big Data Connectorsには、次のものが含まれています。
-
Oracle Loader for Hadoop
-
Oracle SQL Connector for Hadoop Distributed File System
-
Oracle XQuery for Hadoop
-
Oracle R Advanced Analytics for Hadoopの説明は次のとおりです。
-
Oracle Datasource for Apache Hadoop
Oracle Big Data Applianceソフトウェアをインストールする前に、Oracle Big Data Appliance構成生成ユーティリティを使用して、インストール時にOracle Big Data Connectorsを有効にするようにMammothに指示できます。インストール後の任意の時点で、bdacli
ユーティリティを使用してOracle Big Data Connectorsを有効または無効にできます。
# bdacli [enable|disable] bdc
次の項では、Oracle Big Data Connectorsの有効化および無効化の詳細を説明します。
10.9.1.1 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
10.9.1.2 Oracle Big Data Connectorsの削除
Oracle Big Data Connectorsのサポートを削除する場合、MySQL Databaseのrootユーザーのパスワードがcluster_name
-config.json
に保存されていないときは、そのパスワードを指定する必要があります。
次の手順では、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# INFO: Creating environment.pp file ... INFO: Making sure all puppet agents can be accessed. INFO: Pinging puppet agents INFO: Removing big data connectors. This will take some time ... . . . SUCCESS: Successfully reconfigured service
10.9.2 Oracle Big Data Spatial and Graphの有効化または無効化
Oracle Big Data Spatial and Graphは、Oracle Big Data Applianceデプロイメント・バンドルに含まれています。Oracle Big Data Applianceのユーザーは、外部ソースからOracle Big Data Spatial and Graphをダウンロードする必要はありません。
このソフトウェアは、いつでも有効または無効にできます。オプションは次のとおりです。
-
Oracle Big Data Applianceソフトウェアをインストールする前に、Oracle Big Data Appliance構成生成ユーティリティを使用して、インストール時にOracle Big Data Spatial and Graphを有効にするようにMammothに指示できます。
-
インストール後の任意の時点で、
bdacli
ユーティリティを使用してOracle Big Data Spatial and Graphを有効または無効にできます。
# bdacli [enable|disable] osg
関連項目:
-
このガイド内のbdacliリファレンス
10.9.3 自動サービス・リクエストの有効化または無効化
自動サービス・リクエストをサポートするには、次の手順を実行します。
-
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 ... . . .
-
「自動サービス・リクエストのインストールの確認」のステップを完了します。
10.9.4 Kerberos認証の有効化
ノート:
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# . . .
bdacliによってKerberos用に自動構成されるサービス
bdacli enable kerberos
を使用すると、クラスタ全体、およびMammothインストーラで事前構成されているサービス(HDFS、YARN、Spark、Hive、Hue、OozieおよびZookeeper)について、Kerberosが構成されます。これらのサービスについては、これ以上のステップは必要ありません。
HBaseまたはFlumeなどの追加および構成したサービスの場合、Cloudera Managerの使用による各サービス用のKerberosの構成について、Clouderaのドキュメントを参照してください。
10.9.5 Oracle Big Data SQLのインストール
Oracle Big Data SQLでは、Apache Hive、HDFS、Oracle NoSQL Database、Apache HBase、その他のNoSQLデータベース、Oracle Cloud Infrastructure Object Storage、Amazon S3など、複数のビッグ・データ・ソースに格納された非リレーショナル・データに対する問合せをサポートしています。
ノート:
Oracle Big Data SQLをOracle Big Data Applianceにインストールするにはライセンスが必要です。インストールのOracle Database側の追加ライセンスは必要ありません。ライセンス要件の詳細は、Oracle Big Data Applianceライセンス情報ユーザー・マニュアルを参照してください。
Oracle Databaseへのサポートされる接続
-
Oracle Exadata Database Machine
-
Oracle LinuxまたはRHELベースのコモディティ・サーバー上のOracle Database。特定のシステムはOracle Big Data SQL Master Compatibility Matrix (My Oracle SupportのDoc ID 2119369.1)にリストされています
関連項目:
この項は、Oracle Big Data Applianceのユーザーに対するOracle Big Data SQLインストールの概要です。Oracle Big Data SQLのインストール、構成および使用の完全な情報は、これらのドキュメントを参照してください。既存のOracle Big Data SQLインストールへのインストール
ソフトウェアの前のバージョンをアンインストールする必要はありません。インストールによって、以前インストールされたバージョンが現在のリリース・レベルにアップグレードされます。
ノート:
以前のOracle Big Data SQLがすでにOracle Big Data Applianceに存在する場合、構成生成ユーティリティのフォーム・フィールドでインストールにOracle Big Data SQLを選択したかどうかに関係なく、Mammothインストーラはこのインストールを現在のリリース・レベルにアップグレードします。Oracle Big Data Applianceで、ソフトウェアは構成管理サーバー(Cloudera Configuration Managerが実行されているノード)の/opt/oracle/BDSJaguar
にインストールされます。
Kerberos保護環境に対するチケット更新の自動設定
環境がKerberosで保護されている場合、インストールはoracle
アカウント・プリンシパルのチケットを1日に4回更新するcronジョブを自動的に設定します。この頻度は、AD Kerberos要件を満たすためのものです。余分のkinitはMIT Kerberosに無害です。必要に応じて、Oracle Big Data ApplianceとOracle Databaseシステムの両方に対して自動化が設定されます。
10.9.5.1 インストール・オプション
各Oracle Big Data Applianceソフトウェア・リリースには、アプライアンスで使用可能なユーティリティを使用してインストールできる状態のOracle Big Data SQLのバージョンがすでに含まれています。
このガイドで説明しているようにBig Data Applianceユーティリティを使用するオプションがあります。もう1つのオプションは、このBig Data Applianceのリリースと互換性のあるより新しいバージョンが利用可能な場合に、Oracle Software Delivery Cloud (edelivery.oracle.com)からBig Data SQLのスタンドアロン・リリースをダウンロードしてインストールする方法です。ただし、Big Data Applianceでは、推奨される方法はBig Data Applianceソフトウェアに含まれているBig Data SQLパッケージをインストールすることです。
アプライアンスに付属するBig Data SQLのバージョンをインストールする利点は、次のとおりです。
- ソフトウェアのインストールの前提条件がすでに満たされています。
- Big Data Appliance構成生成ユーティリティのチェック・ボックスを選択することによって、Big Data ApplianceリリースのインストールにBig Data SQLを追加できます。Mammothユーティリティは、Big Data SQLをインストールに自動的に含めます。
- 後でbdacliユーティリティを使用して、Big Data SQLをインストールすることもできます。これも簡単な手順です。コマンドは
bdacli enable big_data_sql
です。 - 新しいBig Data Applianceソフトウェア・リリースへのアップグレード中、Mammothは、Big Data Applianceのリリース・バンドルに含まれているバージョンがより新しい場合、Hadoop側のBig Data SQLのインストール環境をリリース・バンドルに含まれているバージョンに自動的にアップグレードします。これは、アプライアンスにすでに存在するBig Data SQLのバージョンがMammoth自体によってインストールされたか、スタンドアロンのインストール・バンドルからインストールされたかにかかわらず行われます。
Big Data Applianceに含まれているBig Data SQLのバージョンのインストールでは、次の制限があります。
- インストールはHadoop側でのみ実行されます。このガイドの説明を使用して、製品のデータベース側をインストールする必要があります。デフォルトのインストールを変更する場合も、このガイドを参照する必要があります。
- Big Data Applianceのリリースに、入手可能な最新バージョンのBig Data SQLが含まれていない場合があります。
このガイドでは、Mammothまたはbdacliを使用してBig Data SQLをインストールする方法について説明します。スタンドアロンのBig Data SQLバンドルを使用してインストールする手順については、Oracle Big Data SQLユーザーズ・ガイドを参照してください。
10.9.5.2 インストールの概要
Oracle Big Data SQLのインストールでは、Oracle Big Data Applianceへのインストール、およびアプライアンスのデータを問い合せるデータベース・システムへのもう1つのインストールを行います。
インストールのフェーズ
-
Oracle Big Data Applianceでのインストール。
Oracle Big Data Appliance構成生成ユーティリティによって、Oracle Big Data SQLをインストールに含めるようにMammothに指示するフォーム・フィールドが提供されます。
Mammothのインストール後、任意のときにbdacliユーティリティを使用してOracle Big Data SQLを有効にすることもできます。
-
Oracle Databaseシステムでのインストール。
インストールのこの部分は手動で実行する必要があります。データベース側のインストール・バンドルは、Oracle Big Data Applianceインストールを実行すると生成されます。このバンドルをOracle Databaseシステムの各コンピュート・ノードにコピーし、解凍してインストールする必要があります。
-
オプションのセキュリティ機能およびユーザー・アクセス機能(デフォルトのインストールに含まれない)の有効化
Oracle Big Data SQLインストールをカスタマイズして、Oracle Big Data Applianceでのデフォルトのインストールでは構成できない次のような機能を含めることができます。
- 問合せサーバー。Hadoopクラスタ・エッジ・ノードに直接インストールする、軽量でメンテナンス不要の18c Oracle Database。これにより、本格的なOracle Databaseシステムを必要とせずに、Hadoopでデータを簡単に問い合せることができます。このサービスは、Oracle SQL問合せエンジンのみで構成されています。セッション間で保持するのに便利なメタデータの特定のカテゴリを除いて、永続記憶域が提供されません。
- マルチ・ユーザーの認可: データベース所有者以外のユーザーが、アプライアンス上のHadoopクラスタのデータに対してOracle Big Data SQLの問合せを実行できます。(デフォルトで有効化されているデータベース認証と同様に)この機能のアクティブ化を完了するには、インストール・プロセスの3番目のステップが必要です。
関連項目:
データベース側バンドルのインストールおよびオプション機能の有効化の方法の詳細は、Oracle Big Data SQLインストレーション・ガイドに説明されています。10.9.5.3 Mammothまたはbdacliを使用したBig Data Appliance側のOracle Big Data SQLのインストール
Big Data SQLは、Mammothまたはbdacliユーティリティでインストールできます。Mammothは、以前のリリースのBig Data SQLがすでにインストールされていることを検出すると、Big Data Appliance側のインストール環境を自動的にアップグレードします。データベース側は手動でアップグレードする必要があります。
ノート:
Mammothまたはbdacliを使用したBig Data SQLのインストールでは、問合せサーバー機能は含められません。問合せサーバーを追加するには、後でインストールを再構成します。これが初回のインストールの場合(前のリリースがインストールされていない)
ソフトウェアをインストールするようにMammothに指示:
Oracle Big Data SQLをOracle Big Data Appliance構成生成ユーティリティで選択することによってMammothインストールに含めることができます。ソフトウェアをインストールする各クラスタに対して選択する必要があります。
次の図に示すように、構成生成ユーティリティの「Cluster Definition」ページでOracle Big Data SQLインストールを設定します。
図10-1 構成生成ユーティリティのOracle Big Data SQLフィールド
-
ライセンスの問いに対して「Yes」を選択すると、他のオプションに進めます。
「Install Big Data SQL?」
に対しても「Yes」を選択します -
Oracle Big Data Applianceがイーサネットまたはインフィニバンド接続によってOracle Databaseシステムに接続されるかどうかを指定します。どちらの方法もサポートされます。
構成ファイルを生成すると、Oracle Big Data SQLインストールを実行する指示が<cluster name>-config.json
ファイルに追加されます。
bdacliを使用したMammoth後インストールの実行:
# bdacli enable big_data_sql
Mammothおよびbdacliはどちらも、選択したクラスタのすべてのDataNodeにOracle Big Data SQLをインストールします。
ノート:
Oracle Linux 6クラスタのみの場合は、Big Data SQLを使用する前に、構成マネージャがホストされているノード(通常はノード3)にPython暗号化モジュールをインストールする必要があります。インターネットからpipをダウンロードしてインストールし、pipを使用して暗号化モジュールをインストールします。sclを使用してPython 2.7を呼び出し、Pythonコマンドを実行します。curl https://bootstrap.pypa.io/get-pip.py -o get-pip.py
scl enable python27 'python get-pip.py'
scl enable python27 'pip install cryptography'
データベース認証のためのGUIDキー・ペアの生成
Oracle Big Data SQLインストレーション・ガイドで説明されているデータベース認証機能を利用するには、GUID/キーのペアを生成してインストールする必要があります。このプロセスは、キーを生成するためにCloudera Configuration Managerがインストールされているノードで次のコマンドを実行することによって開始します。
# ./jaguar --requestdb <database name> databasereq
この後、Oracle Big Data SQLのデータベース側のインストールを実行する前に、そのキーを含むファイルをOracle Databaseサーバーにコピーします。データベース認証の有効化プロセスを完了するには、他にいくつかのステップがあります。キー・ファイルを生成するために使用されるJaguarユーティリティと、キーの生成およびインストールのプロセスについては、Oracle Big Data SQLインストレーション・ガイドのHadoop側のOracle Big Data SQLのインストールまたはアップグレードを一読してください。
以前のリリースのOracle Big Data SQLがすでにインストールされている場合
この場合、構成生成ユーティリティでOracle Big Data SQLを選択する必要はありません。Mammothは、以前のOracle Big Data SQLのリリースを、現在インストールされているすべてのクラスタで現在のバージョンに自動的にアップグレードします。
ノート:
インストールのOracle Database側のアップグレードは自動ではありません。このガイドの説明に従って、ソフトウェアのデータベース側をインストールしてください。10.9.5.4 Oracle DatabaseシステムでのOracle Big Data SQLのインストール
Oracle Big Data ApplianceにOracle Big Data SQLをインストールすると、このプロセスによってデータベース側のインストール・バンドルも生成されます。Oracle Big Data ApplianceのHadoopデータに対してOracle Big Data SQL問合せを実行する予定のデータベース・システムに、このバンドルをインストールします。
データベース側のバンドルをインストールするには、Oracle Big Data SQLインストレーション・ガイドのOracle Big Data SQLのOracle Database側のインストールまたはアップグレードを参照してください。
10.9.5.5 デフォルトのOracle Big Data SQLインストールのカスタマイズ
Mammothまたはbdacliを使用してBig Data SQLをインストールすると、これらのユーティリティによって基本インストールが実行されます。基本インストールでは、使用可能なすべての機能が有効になるとは限りません。
基本インストールの実行後に、Big Data SQLに付属するJaguarユーティリティを使用すると、追加機能を有効にしたり、その他の変更を行うことができます。次に例を示します。
-
マルチユーザー認可の追加。
以前のリリースのOracle Big Data SQLでは、HadoopおよびHiveデータに対するすべての問合せは
oracle
ユーザーとして実行され、ユーザーを変更するオプションはありません。すべての場合でoracle
は引き続き基礎となるユーザーですが、Oracle Big Data SQLでは、Hadoop Secure Impersonationを使用して他の指定されたユーザーのかわりにoracleアカウントにタスクを実行するように指示できるようになりました。これによって、oracle
ユーザーのみではなく、現在問合せを実行しているユーザーに基づくHDFSデータ・アクセスが可能になりました。 -
データベース認証の追加。
これは、Hadoopクラスタ内のOracle Big Data SQLプロセスに対するOracle Database接続の認証です。これは不正なサービスが接続を確立しようとする、なりすまし攻撃に対する保護を提供します。
- 問合せサーバーの追加。
問合せサーバーは、クラスタ管理のエッジ・ノードまたは管理対象外のエッジ・ノードにインストールできます。
-
Oracle Big Data SQLによって使用されるネットワークの切替え。
Oracle Big Data SQLをサポートする物理接続がある場合、Oracle Big Data SQLを再インストールしなくても、Oracle Big Data ApplianceおよびOracle Databaseサーバーをイーサネットからインフィニバンド(またはその逆)に切り替えることができます。
これらの変更を元に戻す場合は、後でインストールをもう一度再構成できます。
Jaguarユーティリティを使用したインストールの再構成
Cloudera Configuration Managerがインストールされているクラスタ・ノード(通常はノード3)で、Big Data SQLのインストール・ディレクトリは/opt/oracle/BDSJaguar
にあります。このディレクトリのJaguarユーティリティを使用して、デフォルトのインストールを再構成します。Jaguarは、インストールの構成可能パラメータを設定するJSONファイルを読み取ります。デフォルトの構成ファイルはbds-config.json
ですが、任意の名前を使用できます。カスタム構成を開始するお薦めの方法は、Mammothによって作成されたデフォルトのbds-config.json
のコピーを作成し、このファイルにカスタマイズを追加することです。
jaguar reconfigure
を実行すると、構成ファイルに設定したパラメータが操作によって読み取られ、インストールのOracle Big Data Appliance側がそれに応じて変更され、また、加えた機能変更をサポートする新しいデータベース側のインストール・バンドルが生成されます。
ノート:
Jaguarは、インストールおよびアンインストールを含む多くの様々な操作を提供します。ただし、Oracle Big Data ApplianceにバンドルされているバージョンのOracle Big Data SQLをインストールした場合は、Jaguarのインストールおよびアンインストール操作を実行しないでください。構成生成ユーティリティまたはbdacliを使用して、ソフトウェアを有効化または無効化してください。
関連項目:
Oracle Big Data SQLインストレーション・ガイドのJaguarユーティリティについておよびJaguar構成パラメータおよびコマンド・リファレンス
重要:
カスタム構成ファイルを作成して使用する場合、ファイルのバックアップを作成して安全な場所に格納するようにしてください。ファイルは構成のレコードであり、後で構成を再作成または変更するために必要になる場合があります。誤って削除したりユーザーによって変更されることを防ぐためだけではありません。次のMammothおよびbdacliの操作は、Oracle Big Data SQLのインストール・ディレクトリ(/opt/oracle/BDSJaguar
)を削除または上書きします。
-
Mammoth拡張(
# mammoth -e
)またはMammothアップグレード(# mammoth -p
)では、Oracle Big Data SQLインストール・ディレクトリが削除されます。 -
再プロビジョニング(
# bdacli admin-cluster reprovision <node name>
)では、ディレクトリの削除を求められます。 -
# bdacli install
の再実行では、カスタム構成がデフォルト構成で上書きされます。
10.9.5.5.1 問合せサーバーの追加
既存のOracle Big Data SQLインストールを再構成して、問合せサーバーを含めることができます。
問合せサーバーは、オプションでBig Data SQLのコンポーネントとしてHadoopクラスタ内のエッジ・ノードにインストールできるOracle Databaseインスタンスです。問合せサーバーは、主として、Oracle外部表を使用してクラスタに格納されているデータ(HDFS形式およびHive形式)を問い合せるために使用します。これにより、Oracle Databaseによって提供されるSQL機能を全面的に利用できます。
この項では、問合せサーバーをインストールする方法について説明します。Oracle Big Data SQLユーザーズ・ガイドの問合せサーバーの使用では、問合せサーバーを使用する方法について説明しています。
10.9.5.5.2 問合せサーバーの前提条件
問合せサーバーをインストールする前に、Big Data Applianceで次の設定を行う必要があります。
- 専用エッジ・ノード
問合せサーバーは、エッジ・ノードにインストールする必要があります。このノードは専用にすることをお薦めします。問合せサーバーは、DataNodeロールおよびBDSSERVERロールが実行されているノードでは実行できません。
エッジ・ノードの要件:
- Oracle Software Delivery Cloud (edelivery.com)にあるQueryServerパッケージ
このパッケージをダウンロードおよびデプロイする手順については、この項で説明します。
- /opt/oracle/BDSjaguar/bds-config.jsonに設定する問合せサーバー固有の構成パラメータ
bds-config.json
ファイルは、有効または無効にする必要がある機能を再構成操作に通知し、操作の完了に必要なパス情報およびその他の情報を提供します。少なくとも構成ファイルのedgedb
セクションのパラメータを構成する必要があります。この項では、エッジ・ノードを問合せサーバーとして使用することを有効にして(ここで無効にすることもできます)、アドレスを指定します。更新を取得するために問合せサーバーを同期化するHiveデータベースのリストを追加することもできます。次に例を示します。"edgedb": { "node" : "dbnode.domain.com", "enabled" : "true", "sync_hive_db_list" : "my_hive_db_1,my_hive_db2" }
Kerberosを使用している場合は、複数のユーザーが問合せサーバーにアクセスできるように、Kerberosパラメータを追加設定できます。そうしない場合は、
oracle
ユーザーのみがアクセスできます。詳細は、Oracle Big Data SQLインストレーション・ガイドのJaguar構成パラメータおよびコマンド・リファレンスを参照してください。
10.9.5.5.3 問合せサーバーのインストール
この方法を使用すると、Oracle Big Data Applianceツール(Mammothまたはbdacli)またはスタンドアロンのBig Data SQLインストーラのどちらを使用してOracle Big Data SQLがインストールされたかにかかわらず、問合せサーバーを追加できます。
要約すると、edelivery.oracle.comから問合せサーバー・バンドルをダウンロードして、それに含まれている実行ファイルを実行します。その後、jaguarユーティリティを使用して、既存のBig Data SQLインストール環境に問合せサーバーを追加します。
開始する前に、前の項で説明した前提条件が満たされていることを確認してください。
問合せサーバーのインストールは、Big Data Applianceに対してのみ行います。データベース側のOracle Big Data SQLインストール環境を変更する必要はありません。
ダウンロードするファイルは次の2つです。問合せサーバー・バンドルの2つの部分を次に示します。
V982741-01_1of2.zip V982741-01_2of2.zip
ノート:
V982738-01.zip
はダウンロードしないでください。このパッケージは、問合せサーバーの追加では必要ありません。
10.9.5.6 Oracle Big Data SQLサービスの管理
Oracle Big Data SQLをアプライアンスにインストールすると、そのbd_cell
サービスがインストールされ、HadoopクラスタのすべてのDataNodeで開始されます。
Oracle Big Data Applianceのbdacliユーティリティは、各DataNodeおよびクラスタ全体でOracle Big Data SQLサービスを管理する操作を提供します。
単一のDataNodeでのサービスのインスタンスの場合:
bdacli {start | stop | restart | status} big_data_sql_server <node name>
クラスタ内のすべてのインスタンスの場合:
bdacli {start | stop | restart | status} big_data_sql_cluster
ノート:
bdacliユーティリティは、クラスタ全体でサービスをインストールまたはアンインストールするための# bdacli {enable | disable} big_data_sql
も提供します。デフォルト以外の構成パラメータを追加してインストールをカスタマイズした場合、これらのコマンドによってカスタム構成がデフォルトの構成で上書きされることに注意してください。これらを使用する場合、Jaguar再構成操作を使用してカスタマイズをリストアできるように、最初にカスタム構成ファイルのコピーをアーカイブしてください。
関連項目:
このガイドのbdacliリファレンスに、Oracle Big Data SQLおよび他のサービスの管理に使用できるbdacli操作を説明しています。10.9.5.7 Oracle Big Data SQLのアンインストール
Oracle Big Data SQLを完全にアンインストールするには、Oracle Big Data ApplianceとOracle Databaseシステムの両方からソフトウェアを削除します。
Oracle Databaseシステムからのアンインストール
Oracle Big Data SQLのデータベース側をインストール/アンインストールするには、bds-database-install.sh
スクリプト・ユーティリティを使用します。
--uninstall
パラメータを指定してbds-database-install.sh
を実行します。 $ /bds-database-install.sh --uninstall --crs=false
ノート:
データベース・ノードでGridが実行されていない場合、またはデータベースでGrid (CRS/ASM)を使用しない場合は、オプションの--crs
パラメータを含めてfalse
に設定します。
--uninstall-as-primary
および--uninstall-as-secondary
パラメータがこのリリースでは非推奨になったことに注意してください。アンインストール・プロセスでプライマリ・クラスタとセカンダリ・クラスタを区別する必要がなくなりました。
Oracle Big Data Applianceからのアンインストール
bdacliを使用して、Oracle Big Data ApplianceのOracle Big Data SQLを無効化(アンインストール)します。
# bdacli disable big_data_sql
このコマンドによって、クラスタ全体のすべてのDataNodeからソフトウェアがアンインストールされます。10.9.6 HBaseの設定と構成
HBaseは、Oracle Big Data Applianceのインストールに含まれていますが、使用する前にさらにステップが必要になります。
10.10 その他の承認済ソフトウェアのインストール
Oracle Big Data Applianceデプロイメント・バンドルに含まれているオプションのソフトウェアに加えて、アプライアンスへのインストールがテスト済および承認済のその他のアプリケーションがあります。
このリストに含まれていないかOracle Big Data Applianceでの使用が承認されていないソフトウェアをインストールする場合は、Oracle Big Data Applianceライセンス情報ユーザー・マニュアルで説明されているガイドラインに従ってください。また、サポート担当者を判断するには、ライセンスのマニュアルを確認してください。
10.10.1 Oracle Enterprise Manager Cloud Controlに対するサポートの追加
Oracle Enterprise Manager Cloud Controlプラグインのインストール
-
予備パッチ(選択したプラグイン・バージョンに必要な場合)をインストールします。
13.1または12.cプラグインによるHTTPSを介したシステム監視を有効にするには、次の表に示されているパッチを最初にインストールする必要があります。これらのパッチは、Oracle Automated Release Updates (ARU)のサイトからダウンロードできます。13.2および13.2PGプラグインの場合、追加のパッチは必要ありません。Enterprise Managerシステム・モニタリング・プラグイン Oracle Big Data Applianceのプラグインをサポートするためのパッチ前提条件 13.2および13.2 PG Enterprise Manager System Monitoringプラグイン。 Oracle Big Data Applianceの場合、具体的な13.2 PGバージョンは
Enterprise Manager for Big Data Appliance (13.2.2.0.0)
です。パッチは必要ありません。 13.1 Enterprise Managerシステム・モニタリング・プラグイン -
OMSサイド・パッチ: 23294904
-
エージェント・プラグイン : 23294778
-
Discoveryプラグイン : 23294785
12.c Enterprise Managerシステム・モニタリング・プラグイン -
OMSサイド・パッチ: 23218275
-
BDAプラグインDiscovery OHパッチ: 23218115および23218109.
-
-
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では、次のターゲットのサポートが追加されました。
-
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)10.10.2 Cloudera Data Science Workbenchのインストール
Cloudera Data Science Workbench (CDSW)は、Oracle Big Data Applianceにインストールできます。
Oracle Linux 7を実行するOracle Big Data Applianceエッジ・ノードにCloudera Data Science Workbenchをインストールできます。Mammoth管理対象または管理対象外のエッジ・ノードを使用できます。
インストール手順は、ClouderaのドキュメントのWebサイト(https://www.cloudera.com/documentation.html)で入手できます。
ノート:
Cloudera Data Science Workbenchは、Oracle Big Data Applianceのライセンスに含まれておらず、Oracle Big Data Applianceではサポートされていません。ライセンスおよびサポート情報については、ClouderaのWebサイトを参照してください。
この製品は、Oracle Big Data Applianceデプロイメント・バンドルに含まれていません。インストール・パッケージをClouderaのWebサイトからダウンロードできます。
関連項目:
-
https://www.cloudera.com/products/data-science-and-engineering/data-science-workbench.htmlのClouderaによるCloudera Data Science Workbenchの説明
-
My Oracle Support (MOS)ノート2177796.1。クラスタ・ノードをMammoth管理対象エッジ・ノードに変換する方法について説明しています。
10.11 ベース・イメージの再インストール
Oracle Big Data Applianceを元の状態に戻す場合、または障害サーバーを交換した場合、ベース・イメージの再インストールが必要になる場合があります。
Oracle Big Data Appliance管理ソフトウェアで説明されているように、オペレーティング・システムおよび様々なユーティリティが、工場出荷時にOracle Big Data Applianceにインストールされています。Mammothでは、Oracle Big Data Applianceソフトウェアを新しいバージョンにアップグレードする前に、必要に応じてベース・イメージが自動的にアップグレードされます。
ラックのすべてまたは一部のイメージを変更できます。ただし、クラスタ内のすべてのサーバーは同じイメージである必要があります。適切な手順を実行します。
10.11.1 単一のOracle Big Data Applianceサーバーのイメージの変更
1つのサーバーのイメージを変更するには、この手順に従います。
注意:
サーバーのイメージを変更すると、すべてのファイルとデータが消去されます。
単一のサーバーにベース・イメージを再インストールするには、次の手順を実行します。
-
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-ol7-<version>_RELEASE/ creating: BDABaseImage-ol7-<version>_RELEASE/Extras/ creating: BDABaseImage-ol7-<version>_RELEASE/Extras/BALANCER/ extracting: BDABaseImage-ol7-<version>_RELEASE/Extras/BALANCER/orabalancer-<version>-h2.zip inflating: BDABaseImage-ol7-<version>_RELEASE/Extras/BALANCER/orabalancer-<version>-h2.noarch.rpm extracting: BDABaseImage-ol7-<version>_RELEASE/Extras/BALANCER/orabalancerdemo-<version>-h2.zip creating: BDABaseImage-ol7-<version>_RELEASE/Extras/CELL/ inflating: BDABaseImage-ol7-<version>_RELEASE/Extras/CELL/bd_cell-<version>_LINUX.X64_160506.11 ...
-
前のステップで作成したサブディレクトリに移動します。
# cd BDABaseImage-ol7-<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
コマンドがエラーなしに成功した場合には、サーバーを再起動します。
10.11.2 Oracle Big Data Applianceラックのイメージの変更
この手順を実行して、ラック全体のイメージを変更します。
ラックのすべてのサーバーにベース・イメージを再インストールするには、次の手順を実行します。
-
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.nnn.nn.37: bda1node01.example.com 192.nnn.nn.38: bda1node02.example.com 192.nnn.nn.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.nnn.nn.37: Filesystem Size Used Avail Use% Mounted on 192.nnn.nn.37: /dev/md2 161G 21G 132G 14% / 192.nnn.nn.38: Filesystem Size Used Avail Use% Mounted on 192.nnn.nn.38: /dev/md2 161G 19G 135G 12% / 192.nnn.nn.39: Filesystem Size Used Avail Use% Mounted on 192.nnn.nn.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-ol7-<version>_RELEASE/ inflating: BDABaseImage-ol7-<version>_RELEASE/biosconfig inflating: BDABaseImage-ol7-<version>_RELEASE/makebdaimage extracting: BDABaseImage-ol7-<version>_RELEASE/BDABaseImage-ol6-<version>_RELEASE.md5sum inflating: BDABaseImage-ol7-<version>_RELEASE/reimagerack inflating: BDABaseImage-ol7-<version>_RELEASE/reimagecluster inflating: BDABaseImage-ol7-<version>_RELEASE/BDABaseImage-ol6-<version>_RELEASE.iso . . .
-
前のステップで作成したサブディレクトリに移動します。
# cd BDABaseImage-ol7-<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の実行の手順については、「ソフトウェアのインストール」。
10.11.3 Oracle Big Data Applianceクラスタのイメージの変更
この手順を実行して、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-ol7-<version>_RELEASE/ creating: BDABaseImage-ol7-<version>_RELEASE/Extras/ creating: BDABaseImage-ol7-<version>_RELEASE/Extras/BALANCER/ extracting: BDABaseImage-ol7-<version>_RELEASE/Extras/BALANCER/orabalancer-<version>-h2.zip inflating: BDABaseImage-ol7-<version>_RELEASE/Extras/BALANCER/orabalancer-<version>-h2.noarch.rpm extracting: BDABaseImage-ol7-<version>_RELEASE/Extras/BALANCER/orabalancerdemo-<version>-h2.zip creating: BDABaseImage-ol7-<version>_RELEASE/Extras/CELL/ inflating: BDABaseImage-ol7-<version>_RELEASE/Extras/CELL/bd_cell-<version>_LINUX.X64_160506.11 ...
-
前のステップで作成したサブディレクトリに移動します。
# cd BDABaseImage-ol7-<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-ol7-<version>_RELEASE/BDABaseImage-ol7-<version>_RELEASE.iso to re-image BDABaseImage-ol7-<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 Mar 12 20:19:54 UTC 2019 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の最新のバージョンにすることができるようになります。
10.12 個別パッチのインストール
個別パッチ・バンドルは、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」を参照してください。
10.13 Mammothソフトウェア・インストールおよび構成ユーティリティ
Mammothは、Oracle Big Data Applianceリリース・ソフトウェアをインストールするためのユーティリティであり、アップグレードやクラスタ拡張を実行するためのユーティリティでもあります。
Mammothを使用するには、root
として第1サーバーにログインし、/opt/oracle/BDAMammothディレクトリに移動する必要があります。構文は次のとおりです。
./mammoth option [cluster_name] ]
このコマンドで、cluster_nameはクラスタの名前です。cluster_nameは、cluster_name
-config.json
に示されているとおり、最初のコマンドに正確に入力する必要があります。その後、cluster_nameはデフォルトで前のmammoth
コマンドで指定されたラックになります。
マルチラック・システムでは、あるラックへのインストールを完了してから、別のラックへのインストールを開始する必要があります。
このガイドの次の項では、Mammothのコマンドライン・オプションをリストして説明します。
10.13.1 Mammothのオプション
Oracle Big Data Applianceソフトウェアのインストール、アップグレードの実行、クラスタの拡張、およびクラスタでのチェックの実行を行うには、Mammothユーティリティを使用します。
Mammothのコマンドライン・オプションは次のとおりです。以前のリリースにあった-j
オプションは削除されました。
- -c
-
Oracle Big Data Applianceのクラスタ・チェックを実行します。
- -e newnode1 newnode2 newnode3...
-
クラスタに追加するサーバーのリストのパラメータ・ファイルを生成します。次に、新しいノードをクラスタに追加して、必要なソフトウェアをノードにインストールします。
同じラックまたは複数のラックにあるリストのサーバーを指定できます。
再起動は、通常は新しいノードおよび工場出荷時の初回更新時のみに実行されます。
生成されるパラメータは、
opt/oracle/BDAMammoth/<cluster_name>-config.json
(<cluster-name
>は拡張されるクラスタの名前です)です。パラメータ・ファイルにパスワードは含まれていないため、Mammothの実行時に入力する必要があります。クラスタ拡張では、拡張でノードのデフォルトのrootパスワードが必要になるため、拡張が完了するまでそのパスワードを保持してください。パスワードは後で必ず変更してください。Oracle NoSQL Databaseクラスタでは、Mammothにより、新しいノードのゾーンの種類を要求されます。既存のゾーン、新しいプライマリ・ゾーンまたは新しいセカンダリ・ゾーンから選択できます。既存のゾーンに追加する場合は、使用できるゾーンの一覧が表示されます。新しいゾーンを作成する場合は、ゾーンの名前およびレプリケーション・ファクタを要求されます。
-r (範囲)オプションまたは-s (ステップ)オプションは、次のようにmammoth -eと組み合せて使用できます。# mammoth -r 1-4 -e newnode1 newnode2 newnode3...
# mammoth -s 2 -e newnode1 newnode2 newnode3...
- -h
-
コマンドの使用方法とステップのリストが含まれるコマンド・ヘルプを表示します。
- -i cluster_name
-
クラスタですべての必須ステップを実行します。フル・ラックの場合は、
-r 1-18
と同じです。このオプションは、新しいラックを構成する場合や、クラスタにサーバー・グループを追加する場合に使用します。 - -l
-
Mammothインストールのステップをリストします。
- -p
-
クラスタのソフトウェアを最新バージョンにアップグレードするか、個別パッチをインストールします。
-r (範囲)オプションまたは-s (ステップ)オプションは、次のようにmammoth -pと組み合せて使用できます。# mammoth -r 1-4 -p
# mammoth -s 2 -p
- -r n-N
-
エラーが発生しないかぎり、MammothのステップnからNまでを実行します。
- -s n
-
ステップnを実行します。同じラックの別のクラスタを指定するには、cluster_nameを入力します。デフォルトは現在のクラスタです。
-e
オプションを参照してください。ノート:
-sおよび-rでは、インストール、アップグレードまたは拡張のステップが正しい順序で実行されます。これらのオプションを使用してステップをバイパスすることはできません。 - -v
-
Mammothのバージョン番号を表示します。
10.13.2 Mammothインストールのステップ
Mammothは、Oracle Big Data Applianceリリースのインストールで、次の一連のステップを実行します。
- ステップ1 PreinstallChecks
-
このステップでは、次の複数のタスクが実行されます。
-
構成ファイルを検証し、パスワードを要求します。
-
パスワードを入力せずに管理ネットワークのすべてのアドレスに接続できるように、rootユーザーに対してセキュア・シェル(SSH)を設定します。
-
インフィニバンド・ネットワークのrootユーザーに対してパスワードなしSSHを設定します。
-
構成ファイルから
/etc/hosts
を生成し、インフィニバンド接続を使用して内部的に通信できるようにそれをすべてのサーバーにコピーします。このファイルによって、プライベートIPアドレスがパブリック・ホスト名にマップされます。 -
Mammothが実行されるノードをPuppetマスター・ノードとして識別するための別名を設定します。たとえば、IPアドレス192.nnn.nn.1でbda1node01からMammothを実行した場合、そのIPアドレスの別名のリストにはbda1node01-masterが含まれています。Mammothでは、ソフトウェア・インストールにPuppetを使用します。
-
すべてのノードでネットワーク・タイミングを確認します。タイミング・チェックに失敗した場合、インストールの正常な実行を妨げる未解決の名前およびIPアドレスが存在します。インストールを続行する前に、これらの問題を修正してください。
このステップでは、様々なハードウェアおよびソフトウェア・チェックも実行されます。次のチェックのいずれかに失敗すると、Mammothも失敗します。
-
ARPキャッシュ問合せ時間が2秒以下であること。
-
すべてのサーバー・クロックが現在のサーバーの10秒以内で同期していること。
-
すべてのサーバーが前回の再起動に成功し、
/root/BDA_REBOOT_SUCCEEDED
ファイルが生成されていること。 -
bdacheckhw
ユーティリティが成功したこと。 -
bdachecksw
ユーティリティが成功したこと。
-
- ステップ2 SetupPuppet
-
このステップでは、すべてのノードでPuppetエージェントを構成して起動し、Mammothが実行されているノードでPuppetマスターを構成し、エージェントが証明書を発行するのを待機してその署名を自動化します。このステップでは、すべてのノードのrootパスワードの変更も行います(オプション)。このステップが完了すると、Puppetはソフトウェアをデプロイできます。
Puppetは、Hadoopクラスタを管理するために一般的に使用される分散構成管理ツールです。Puppetマスターは、親のサービスであり、Puppetリポジトリを管理します。Puppetエージェントは、各Hadoopノードで動作します。
/etc/puppet/puppet.conf
という名前のファイルがすべてのサーバーに存在し、Puppetマスターの場所を指定します。Puppetは2つのモードで動作します。
-
定期的プル・モード: Puppetエージェントは定期的にPuppetマスターと通信し、更新の有無を確認します。
-
キック・モード: Puppetマスターは、構成の更新が使用できるというアラートをPuppetエージェントに通知し、エージェントは更新の有無を確認します。Puppetは、Mammothのインストール中はキック・モードで動作します。
どちらのモードでも、Puppetマスターは、エージェントを信頼する必要があります。この信頼を確立するため、エージェントは、
システム
管理プロセスによる署名が行われるPuppetマスター・ノードに証明書を送信します。このトランザクションが完了すると、Puppetマスターは、エージェントに新しい構成を送信します。後続のステップでは、「インストール中にエラーが発生した場合の対処方法」の説明に従って、各サーバーのPuppetログ・ファイルを確認できます。
-
- ステップ3 UpdateBaseImage
-
最新のOracle Big Data Applianceイメージおよびシステム・パラメータ設定をインストールします。カーネルがアップグレードされた場合、システムは自動的に再起動します。
- ステップ4 PrepareBaseImage
-
-
ライセンス契約の要件に応じて、サード・パーティ・ライセンスをすべてのサーバーの
/opt/oss/src/OSSLicenses.pdf
にコピーします。 -
ライセンス契約の要件に応じて、サード・パーティ・ソフトウェアのソース・コードをすべてのサーバーの
/opt/oss/src/
にコピーします。Mammothはソース・コードをOracle NoSQL Databaseクラスタにコピーしません。
-
hdfs
およびmapred
ユーザーと、hadoop
グループを作成します。また、oracle
ユーザーと、dba
およびoinstall
グループも作成します。後のステップでインストールされる様々なパッケージによっても、インストール中にユーザーおよびグループが作成されます。
関連項目:
ユーザーおよびグループの詳細は、『Oracle Big Data Applianceソフトウェア・ユーザーズ・ガイド』を参照してください。
-
NameNodeデータが設定されているディスクまたはノード全体で障害が発生した場合にこの重要な情報の損失を防ぐため、このデータを複数の場所にコピーします。
-
- ステップ5 SetupMySQL
-
MySQL Databaseをインストールして構成します。このステップでは、Cloudera Managerで使用するためにnode03にプライマリ・データベースと複数のデータベースが作成されます。また、node02のバックアップ・データベースに対するプライマリ・データベースのレプリケーションも設定されます。
MammothはOracle NoSQL DatabaseクラスタにMySQL Databaseをインストールしません。
- ステップ6 SetupKDC
-
クラスタでセキュリティを設定するために使用されるKerberosキー配布センター(KDC)を構成します。
- ステップ7 InstallHadoop
-
Cloudera's Distribution including Apache Hadoop (CDH)およびCloudera Managerのすべてのパケットをインストールします。その後、node03でCloudera Managerサーバーを起動し、クラスタを構成します。
MammothはOracle NoSQL DatabaseクラスタにCDHまたはCloudera Managerをインストールしません。
- ステップ8 StartHadoopServices
-
すべてのノードのエージェントを起動し、すべてのCDHサービスを開始します。HTTPS/ネットワーク暗号化が有効になっている場合は、Cloudera Manager、HueおよびOozieに対してもHTTPSを有効にします。
このステップの後、Hadoopインストール環境が完全に機能します。
Cloudera Managerは、node03のポート7180で実行されます。これは次のようにブラウザで開くことができます。
http://bda1node03.example.com:7180
この例では、bda1node03がnode03の名前で、
example.com
がドメインです。デフォルトのユーザー名とパスワードはadmin
です。パスワードはこのステップの最後に変更するように求められます。Oracle NoSQL Databaseクラスタでは、MammothはCDHサービスをインストールも開始もしません。
- ステップ9 InstallBDASoftware
-
Oracle Big Data Appliance構成生成ユーティリティでこのオプションを選択した場合は、Oracle Big Data Connectorsのサーバー側コンポーネントをインストールします。Oracle Big Data Connectorsにはライセンスが別途必要です。オプションです。
Oracle Big Data Appliance構成生成ユーティリティでこのオプションを選択した場合は、Oracle Big Data SQLのサーバー側コンポーネントをインストールします。Oracle Big Data SQLにはライセンスが別途必要です。
Oracle NoSQL Databaseを使用するために割り当てられたクラスタに、Oracle NoSQL Databaseをインストールします。Enterprise Editionにはライセンスが別途必要です。
- ステップ10 SetupHadoopSecurity
-
このステップで実行されるアクションは、インストールに先立って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でキー配布センターを設定している場合には、前提条件はありません。それ以外の場合には、「インストールの前提条件」を参照してください。
-
- ステップ11 SetupASR
-
自動サービス・リクエスト(ASR)をインストールして構成します。オプションです。
このステップでは、次のことが実行されます。
-
必要なソフトウェア・パッケージをインストールします。
-
トラップ宛先を構成します。
-
監視デーモンを起動します。
ASRマネージャからアセットをアクティブ化するには、「ASRアセットの確認」を参照してください。
注意:
このステップを正常に実行するには、ASRマネージャが実行され、適切に構成されたASRホスト・システムが稼働している必要があります。「自動サービス・リクエストの設定」を参照してください。
-
- ステップ12 CleanupInstall
-
次のことが実行されます。
-
Cloudera Managerパスワードを変更します(インストール・テンプレートに指定されている場合)。
-
インストール中に作成された一時ファイルを削除します。
-
すべてのノードから
/opt/oracle/bda/install/log
のサブディレクトリにログ・ファイルをコピーします。 -
クラスタ検証チェック(TeraSortを含む)を実行して、すべてが適切に動作することを確認します。また、インストール・サマリーも生成されます。すべてのログは、node01の
/opt/oracle/bda/install/log
以下のサブディレクトリに格納されます。
-
- ステップ13 CleanupSSHroot (オプション)
-
「PreinstallChecks」で設定した
root
のパスワードなしSSHを削除します。
10.14 Oracle Big Data Applianceベース・イメージ・ユーティリティ
次のイメージ・ユーティリティは、ベース・イメージのバンドルで配布されています。
これらのユーティリティを実行するには、root
としてログインする必要があります。
10.14.1 makebdaimage
単一のサーバー、クラスタ、またはラック全体にベース・イメージを再インストールします。reimagecluster
とreimagerack
のどちらもこのユーティリティを呼び出します。
makebdaimage
ユーティリティには次の構文があります。
makebdaimage [--usb | --usbint] [--noiloms] /path/BDABaseImage-version_RELEASE.iso /path/BDdaDeploy.json target_servers
オプション
- --usb | --usbint
-
イメージの変更に使用するUSBポートを指定します。外部USBドライブの場合は
--usb
、内部ドライブの場合は--usbint
を使用します。内部USBドライブにはLinuxの完全インストールが含まれます。--usbint
オプションを使用するには、ターゲット・サーバーにログインしている必要があります。ログインしていないと、間違ったネットワーク情報を使用してサーバーのイメージを変更する可能性があります。 - --noiloms
-
イメージの変更処理によって、ターゲット・サーバー上のOracle ILOMが変更されることはありません。
- target_servers
-
イメージをインストールする1つ以上のサーバーを示し、次のいずれかの書式で指定します。
-
node_number
イメージを変更する単一のサーバーを指定します。サーバーのラック上の位置を下から数えて1から18で入力します。
-
from.json to.json
現在の構成(
from
.json
)と必要な構成(to
.json
)を指定します。JSONファイルは、BdaShip.json
の工場出荷時の構成またはnetwork.json
のカスタム構成のいずれでもかまいません。構成されたサーバーの/opt/oracle/bda
にあります。 -
to.json:
network.json
やBdaShip.json
に類似の連結されたJSONファイルですが、ETH0_MACSアレイ・エントリが追加されています。連結ファイルの最初のエントリと対応するeth0_macエントリがイメージを変更するときに使用されます。to
.json
ファイルはそのまま使用されます。
-
10.14.2 reimagecluster
dcli
とmakebdaimage
を使用して、クラスタ内のすべてのサーバーのイメージを同時に変更します。
reimagecluster
ユーティリティには次の構文があります。
reimagecluster [--no-iloms]
前提条件
-
次のコマンドがクラスタ内のサーバーのリストを返すことを確認します。
$ dcli -C hostname
-
BDABaseImage-
version
_RELEASE*.iso
ファイルが現在のディレクトリに1つだけあることを確認します。
10.14.3 reimagerack
dcli
とmakebdaimage
を使用して、ラック内のすべてのサーバーのイメージを同時に変更します。
reimagerack
ユーティリティには次の構文があります。
reimagerack [--no-iloms] [--no-macs] [--hosts n1, n2...] [from.json [to.json]]
前提条件
-
次のコマンドがラック内のサーバーのリストを返すことを確認します。
$ dcli -hostname
-
BDABaseImage-
version
_RELEASE*.iso
ファイルが現在のディレクトリに1つだけあることを確認します。
オプション
- --no-iloms
-
イメージの変更処理によって、ターゲット・サーバー上のOracle ILOMが変更されることはありません。
- --no-macs
-
このユーティリティはサーバーのMACアドレスを取得しません。かわりに、インフィニバンドのケーブル配線を使用します。このオプションは、工場出荷時の設定を復元する場合にのみ使用します。コマンドラインに両方のJSONファイル(
from
.json
とto
.json
)が含まれている必要があります。 - --hosts n1, n2...
-
ホスト名またはIPアドレスのカンマ区切りのリストのうち、
dcli
が受け入れたいずれかのリストで指定されたサーバーのイメージの変更を制限します。すべてのサーバーは、dcli -t
コマンドで指定されたターゲット・サーバーのリストに含まれている必要があります。このオプションでは
--no-macs
オプションが強制的に実行されるため、その制限も適用されます。 - from.json
-
現在の構成ファイル(
BdaShip.json
またはnetwork.json
)へのフルパスです。このオプションのデフォルト値は、
/opt/oracle/bda/network.json
です。network.json
が見つからない場合、オプションのデフォルト値は、/opt/oracle/bda/BdaShip.json
です。サーバーは事前にreimagerack
で使用されているJSONファイルの値に設定されている必要があります。 - to.json
-
イメージの変更後に有効になる新しいネットワーク構成へのフルパスです。
network.json
ファイルまたはBdaShip.json
ファイルのいずれかになります。