| Oracle® Big Data Applianceソフトウェア・ユーザーズ・ガイド リリース2 (2.5) E53260-01 |
|
 前 |
 次 |
この章では、Oracle Big Data Applianceにインストールされるソフトウェアおよびサービスについて説明します。次の項について説明します。
Oracle Enterprise Managerプラグインでは、Oracle Exadata Database Machineや他のOracle Databaseインストールに使用するのと同じシステム監視ツールをOracle Big Data Applianceに使用できます。プラグインを使用して、インストールされたソフトウェア・コンポーネントのステータスを表や図式を使用した形式で表示したり、これらのソフトウェア・サービスの起動や停止を行えます。ネットワークおよびラック・コンポーネントの状態を監視することもできます。
Oracle Enterprise Manager Webインタフェースを開いてログインし、ターゲット・クラスタを選択すると、次の主要領域へドリルダウンできます。
インフィニバンド・ネットワーク: インフィニバンド・スイッチとポートのネットワーク・トポロジとステータス。図2-1を参照してください。
Hadoopクラスタ: HDFS、MapReduceおよびZooKeeperのソフトウェア・サービス。
Oracle Big Data Applianceラック: サーバー・ホスト、Oracle Integrated Lights Out Manager (Oracle ILOM)サーバー、配電ユニット(PDU)、イーサネット・スイッチなどのハードウェア・ステータス。
図2-1は、クラスタ・ホームページの一部を示しています。
Oracle Enterprise Managerを使用してOracle Big Data Applianceを監視するには、次の手順を実行します。
プラグインをダウンロードしてインストールします。『Oracle Enterprise Manager System Monitoring Plug-inインストレーション・ガイドfor Oracle Big Data Appliance』を参照してください。
管理ユーザーとしてOracle Enterprise Managerにログインします。
「ターゲット」メニューから「ビッグ・データ・アプライアンス」を選択し、ビッグ・データ・ページを表示します。Oracle Enterprise Managerによって検出済のターゲットの全体的なステータスが表示されます。
詳細ページを表示するターゲット・クラスタを選択します。
ターゲット・ナビゲーション・ツリーを展開し、コンポーネントを表示します。すべてのレベルで情報を使用可能です。
ツリーでコンポーネントを選択し、ホーム・ページを表示します。
表示を変更するには、メイン表示領域の左上部にあるドロップダウン・メニューから項目を選択します。
|
関連項目: インストール手順と使用例については、『Oracle Enterprise Manager System Monitoring Plug-inインストレーション・ガイドfor Oracle Big Data Appliance』を参照してください。 |
Enterprise Managerコマンドライン・インタフェース(emcli)はOracle Big Data Applianceに、他のすべてのソフトウェアとともにインストールされます。このインタフェースは、Webインタフェースと同じように機能します。Oracle Management Serverに接続するための資格証明を入力する必要があります。
ヘルプを表示するには、emcli helpと入力してください。
|
関連項目: 『Oracle Enterprise Managerコマンドライン・インタフェース・ガイド』 |
Oracle Big Data ApplianceにインストールされるCloudera Managerは、Cloudera's Distribution including Apache Hadoop (CDH)の操作に役立ちます。Cloudera Managerは、Hadoopクラスタの一部として構成されたすべてのOracle Big Data Applianceサーバーを対象とする単一の管理インタフェースを備えています。
Cloudera Managerを使用すると、次の管理タスクを簡単に行うことができます。
ジョブおよびサービスの監視
サービスの開始および停止
セキュリティ資格証明とKerberos資格証明の管理
ユーザー・アクティビティの監視
システムの状態の監視
パフォーマンス・メトリックの監視
ハードウェアの使用状況の追跡(ディスク、CPU、RAM)
Cloudera Managerは、JobTrackerノード(node03)上で動作し、ポート7180上で使用できます。
Cloudera Managerを使用するには、次の手順を実行します。
ブラウザを開き、次のようにURLを入力します。
http://bda1node03.example.com:7180
この例で、bda1はアプライアンス名、node03はサーバー名、example.comはドメイン、7180はデフォルトのポート番号(それぞれCloudera Managerで使用)を示します。
Cloudera Managerのユーザー名とパスワードでログインします。設定を変更できるのは、管理者権限を持つユーザーのみです。その他のCloudera Managerユーザーは、Oracle Big Data Applianceのステータスを表示できます。
|
関連項目: Cloudera Manager Monitoring and Diagnostics Guideまたは、Cloudera Managerの「Help」メニューで、「Help」をクリックしてください |
Cloudera Managerでは、画面上部のメニュー・バーから、次に示す任意のページを選択できます。
Home: クラスタ上のアクティビティの概要をグラフィカルに表示し、Cloudera Managerによって制御されているすべてのサービスにリンクします。図2-2を参照してください。
Services: Oracle Big Data Appliance上で実行されているサービスのステータスと状態のトップレベル・ビューで、「Services」メニューから「All Services」を選択できます。あるいは、詳細情報を表示する特定のサービスを選択できます。
Hosts: クラスタのすべてのサーバーの状態、ディスク使用量、負荷、物理メモリー、スワップ領域などの統計情報を監視します。
Activities: 指定期間に実行されているすべてのMapReduceジョブを監視します。
Diagnose: 「Diagnose」メニューからイベントまたはログを表示できます。Cloudera Managerは、システムとサービスに関する履歴情報を収集します。選択したサーバー、サービス、および期間を対象に、特定の句を検索できます。また、ログ・メッセージの最小重大度(TRACE、DEBUG、INFO、WARN、ERRORまたはFATAL)を選択して、検索に含めることもできます。
Audits: 選択した時間範囲の監査履歴ログを表示します。ユーザー名、サービスまたはその他の条件によって結果を絞り込み、CSVファイルとしてログをダウンロードできます。
Charts: Cloudera Managerの時系列データ・ストアからメトリックを表示します。折れ線グラフ棒グラフなど、様々なタイプのグラフを選択できます。
Reports: ディスクおよびMapReduceの使用状況に関するレポートをオンデマンドで生成します。
Administration: 「Administration」メニューから、「Settings」、「Alerts」、「Users」、「Kerberos」など各種のオプションを選択します。
図2-2に、Cloudera Managerのホームページを示します。
Cloudera Manager管理者は、Oracle Big Data Applianceの状態や使用状況を監視するための様々なプロパティの変更、ユーザーの追加、およびKerberosセキュリティの設定を行うことができます。
Cloudera Manager Administrationにアクセスするには、次の手順を実行します。
管理者権限でCloudera Managerにログインします。
「Administration」タブを選択します。
Cloudera Managerは次のサービスを管理するインタフェースを備えています。
HDFS
Hive
Hue
MapReduce
Oozie
ZooKeeper
Cloudera Managerを使用すると、これらのサービスの設定変更、停止および再開を行うことができます。追加のサービスも使用できますが、使用する前に構成が必要です。「未構成のソフトウェア」を参照してください。
|
注意: Linuxサービス・スクリプトやHadoop構成ファイルを手動で編集しても、これらのサービスには何の効果もありません。これらを管理および構成するには、Cloudera Managerを使用する必要があります。 |
MapReduceジョブを監視するために、Cloudera Managerのユーザー名とパスワードは必要ありません。
Hadoop Map/Reduce Administrationでは、Oracle Big Data ApplianceのJobTrackerノード(node03)のポート50030で実行されるJobTrackerを監視します。
JobTrackerを監視するには、次の手順を実行します。
ブラウザを開き、次のようにURLを入力します。
http://bda1node03.example.com:50030
この例で、bda1はアプライアンス名、node03はサーバー名、50030はデフォルトのポート番号(それぞれHadoop Map/Reduce Administrationで使用)を示します。
図2-3は、「Hadoop Map/Reduce Administration」画面の一部を示しています。
Task Tracker Statusインタフェースでは、単一ノード上のTaskTrackerを監視します。Oracle Big Data Appliance内にあるすべての非クリティカル・ノード(node04からnode18)のポート50060上で使用できます。6ノードのクラスタの場合、TaskTrackerはnode01とnode02でも実行されます。
TaskTrackerを監視するには、次の手順を実行します。
ブラウザを開き、次のように特定のノードのURLを入力します。
http://bda1node13.example.com:50060
この例で、bda1はラック名、node13はサーバー名、50060はデフォルトのポート番号(それぞれTask Tracker Statusインタフェースで使用)を示します。
図2-4は、Task Tracker Statusインタフェースを示しています。
Hueはブラウザで動作し、複数のアプリケーションに使いやすいインタフェースを提供して、HadoopとHDFSの操作をサポートします。Hueを使用すると、次のタスクを実行できます。
Hiveデータ・ストアの問合せ
Hive表の作成、ロードおよび削除
HDFSファイルおよびディレクトリの操作
MapReduceジョブの作成、発行および監視
MapReduceジョブの監視
Oozieダッシュボードを使用したワークフローの作成、編集および発行
ユーザーおよびグループの管理
HueはJobTrackerノード(node03)のポート8888上で動作します。
Hueを使用するには、次の手順を実行します。
この例で示したようなアドレスを使用し、ブラウザでHueを開きます。
http://bda1node03.example.com:8888
この例で、bda1はクラスタ名、node03はサーバー名、example.comはドメインをそれぞれ示します。
Hue資格証明を使用してログインします。
Oracle Big Data Applianceは、初期設定では特定のHueユーザー・アカウントを使用するよう構成されていません。Hueに最初に接続するユーザーは、任意のユーザー名とパスワードでログインでき、自動的に管理者になります。このユーザーは、他のユーザーと管理者アカウントを作成できます。
上部のアイコンを使用して、ユーティリティを開きます。
図2-5は、Hive問合せを入力するためのBeeswax Query Editorを示しています。
|
関連項目: Oracle Big Data Applianceにすでにインストールおよび構成されているHueの使用方法の詳細は、次のサイトで『Hue Installation Guide』を参照してください |
次の各項では、Oracle Big Data Applianceにインストールされるソフトウェアと、そのラック内での実行場所について説明します。一部のコンポーネントは、Oracle Database 11.2.0.2以降のリリースで動作します。
これらのソフトウェア・コンポーネントは、クラスタのすべてのサーバーにインストールされます。Oracle Linux、必須ドライバ、ファームウェアおよびハードウェア検証ユーティリティは工場出荷時にインストール済です。その他のソフトウェアは、すべてサイトにインストールします。オプションのソフトウェア・コンポーネントは、インストールで構成されない場合があります。
|
注意: Oracle Big Data Applianceに追加のソフトウェアをインストールする必要はありません。これを行うと、保証やサポートの対象外となる可能性があります。詳細は、『Oracle Big Data Applianceオーナーズ・ガイド』を参照してください。 |
ベースとなるイメージ・ソフトウェア:
Oracle Unbreakable Enterprise Kernelバージョン2 (UEK2)を搭載したOracle Linux 6.4 (アップグレードは5.8のまま)
Java HotSpot Virtual Machine 7バージョン25 (JDK 7u25)
Oracle R Distribution 3.0.1-2
MySQL Database 5.5.17 Advanced Edition
Puppet、ファームウェア、ユーティリティ
Mammothインストール:
Apache Sentry 1.1.0
Cloudera's Distribution including Apache Hadoop Release 4 Update 4 (4.6)
Cloudera Impala 1.2.3
Cloudera Navigator 1.1.0
Cloudera Search 1.2.0
Oracle NoSQL Database Community EditionまたはEnterprise Edition 12c Release 1 (オプション)
Oracle Big Data Connectors 2.5 (オプション):
|
関連項目: Mammothユーティリティの詳細は、『Oracle Big Data Applianceオーナーズ・ガイド』を参照してください。 |
図2-6は、主要コンポーネント間の関係を示しています。
各サーバーには12基のディスクが搭載されています。重要なオペレーティング・システムはディスク1および2に格納されます。
表2-1に、ディスク・パーティションの内容を示します。
この項の内容は次のとおりです。
Cloudera Managerを使用すると、Oracle Big Data Appliance上のCDHサービスを監視できます。
サービスを監視するには、次の手順を実行します。
Cloudera Managerで、「Services」タブをクリックし、サービス名をクリックしてその「Status」ページを表示します。
表示する情報のサブタブ、たとえば「Status」、「Instances」、「Commands」、「Configuration」または「Audits」をクリックします。
すべてのサービスはCDHクラスタ内の全ノード上にインストールされますが、個々のサービスは指定されたノードでのみ実行されます。サービスの場所は、クラスタの構成によって多少異なります。
表2-2は、シングル・ラック内に構成されたCDHクラスタ内のサービスを示したものです(6ノードを使用したスタータ・ラックやクラスタを含む)。Node01はクラスタ内の最初のサーバー(サーバー1、7または10)で、nodexxはクラスタ内の最後のサーバー(サーバー6、9、12または18)です。
表2-2 シングル・ラック内にある1つ以上のCDHクラスタのサービス・ロケーション
| node01 | node02 | node03 | Node04 | Node05～nn |
|---|---|---|---|---|
|
バランサ |
||||
|
Hive、Hue、Oozie |
||||
|
Cloudera Manager Agent |
Cloudera Manager Agent |
Cloudera Manager Agent |
Cloudera Manager Agent |
Cloudera Manager Agent |
|
Cloudera Manager Server |
||||
|
DataNode |
DataNode |
DataNode |
DataNode |
DataNode |
|
Failover Controller |
Failover Controller |
Failover Controller |
Failover Controller |
|
|
JournalNode |
JournalNode |
JournalNode |
||
|
MySQL Backup |
MySQL Primary |
|||
|
NameNode 1 |
NameNode 2 |
|||
|
Oracle Data Integratorエージェント |
||||
|
Puppet |
Puppet |
Puppet |
Puppet |
Puppet |
|
Puppet Master |
||||
|
JobTracker 1 |
JobTracker 2 |
|||
|
Task Tracker脚注 1 |
Task Tracker脚注 1 |
TaskTracker |
TaskTracker |
TaskTracker |
|
ZooKeeper Server |
ZooKeeper Server |
ZooKeeper Server |
脚注 1 スタータ・ラックと6ノード・クラスタのみ、スロットの減少数について
複数のラックが単一のCDHクラスタとして構成されている場合、一部の重要なサービスが第2ラックの第1サーバーへと移動されます。
第2ラックの第1サーバーで実行される重要なサービス:
バランサ
Failover Controller
Journal Node
NameNode 1
ZooKeeper Server
DataNode、Cloudera Manager AgentおよびPuppetサービスもこのサーバーで実行されます。
表2-3は、マルチラック・クラスタの最初のラックで実行されるサービスの場所を示したものです。
表2-3 マルチラックCDHクラスタの最初のラックでのサービス・ロケーション
| node01 | node02 | node03 | Node04 | Node05～nn脚注 1 |
|---|---|---|---|---|
|
Cloudera Manager Agent |
Cloudera Manager Agent |
Cloudera Manager Agent |
Cloudera Manager Agent |
Cloudera Manager Agent |
|
Cloudera Manager Server |
||||
|
DataNode |
DataNode |
DataNode |
DataNode |
DataNode |
|
Failover Controller |
Failover Controller |
Failover Controller |
||
|
Hive、Hue、Oozie |
||||
|
JournalNode |
JournalNode |
|||
|
MySQL Backup |
MySQL Primary |
|||
|
NameNode 2 |
||||
|
Oracle Data Integratorエージェント |
||||
|
Puppet |
Puppet |
Puppet |
Puppet |
Puppet |
|
Puppet Master |
||||
|
JobTracker 1 |
JobTracker 2 |
|||
|
TaskTracker |
TaskTracker |
TaskTracker |
TaskTracker |
|
|
ZooKeeper Server |
ZooKeeper Server |
脚注 1 nnには追加ラック内のサーバーが含まれます。
NameNodeは、すべてのデータの場所を追跡するため、最も重要なプロセスです。正常に機能しているNameNodeがないと、クラスタ全体に障害が発生します。Apache Hadoop v0.20.2以前のバージョンは、ネームノードが1つしかないため、障害に対して脆弱です。
Cloudera's Distribution including Apache Hadoopのバージョン4 (CDH4)では、NameNodeの冗長性を維持することにより、この脆弱性が軽減されています。次に示すように、データは通常の運用時にレプリケートされます。
CDHは、最初の2つのノード上でNameNodeの冗長性を維持します。NameNodeの一方はアクティブ・モード、もう一方のNameNodeはホット・スタンバイ・モードです。アクティブNameNodeに障害が発生すると、そのアクティブNameNodeのロールは自動的にスタンバイNameNodeにフェイルオーバーされます。
NameNodeのデータはミラー化されたパーティションに書き込まれるので、1つのディスクが失われても耐障害性が確保されます。このミラー化の処理は、オペレーティング・システムのインストールの一環として工場出荷時に行われます。
アクティブNameNodeでは、ファイル・システム・メタデータへのすべての変更を2つ以上のJournalNodeプロセスに記録し、これをスタンバイNameNodeが読み取ります。3つのJournalNodeがあり、それらは各クラスタの最初の3つのノードで実行されます。
ジャーナルに記録された変更は、チェックポインティングと呼ばれるプロセスで単一のfsimageファイルに定期的に統合されます。
|
注意: Oracle Big Data Appliance 2.0以降のリリースでは、バックアップ用の外部NFSフィルタをサポートしておらず、NameNodeのフェデレーションを使用しません。 |
図2-7は、NameNodeの自動フェイルオーバーをサポートしているプロセス間の関係を示しています。
図2-7 Oracle Big Data ApplianceでのNameNodeの自動フェイルオーバー
JobTrackerは、MapReduceタスクをクラスタ全体に分散します。NameNodeと同様、JobTrackerはノードの重要な障害ポイントです。JobTrackerで障害が起きると、すべてのジョブが実行を停止します。
Oracle Big Data Appliance 2.2以降のリリースでは、この脆弱性を緩和するためにCDH4でのJobTracker High Availableがサポートされています。
CDHは、node03と-04上の冗長なJobTrackerサービスを管理します。それらのサービスの1つがアクティブ・モードになり、その他のサービスはホット・スタンバイ・モードになります。サービスの状態は、2つのノード上のフェイルオーバー・コントローラによって監視されます。アクティブ・サービスに障害が発生すると、そのアクティブJobTrackerのロールは自動的にスタンバイJobTrackerにフェイルオーバーされます。
図2-7は、NameNodeの自動フェイルオーバーをサポートしているプロセス間の関係を示しています。
図2-8 Oracle Big Data ApplianceでのJobTrackerの自動フェイルオーバー
次のツールは使用しているOracle Big Data Applianceライセンスに含まれており、Mammothユーティリティによって他のCDHコンポーネントとともにインストールされます。これらは、Cloudera Webサイトからはダウンロードしないでください。ただし、使用可能にするには構成する必要があります。
Cloudera BDR (Cloudera Managerに組込み)
Cloudera Impala
Cloudera Navigator (Cloudera Managerに組込み)
Cloudera Search
各クラスタの最初のサーバー上のRPMファイルは、/opt/oracle/BDAMammoth/bdarepo/RPMS/noarchにあります。
|
関連項目: 構成の手順の詳細は、次のサイトで『CDH4 Installation and Configuration Guide』を参照してください |
クラスタ内の各ノードには、同時実行を許可されるマップ・タスクとリデュース・タスクの最大数があります。表2-4は、Oracle Big Data Appliance X4-2およびX3-2でのMapReduceサービスのデフォルトのリソース構成を示したものです。
表2-4 Oracle Big Data Appliance X3-2でのマップおよびリデュース・タスクの最大数
| ノード | 6ノード・クラスタ | より大規模なクラスタ脚注 1 |
|---|---|---|
|
Node01とNode02 |
14マップ 8リデュース |
なし |
|
Node03とNode04 |
10マップ 6リデュース |
10マップ 6リデュース |
|
Node05～Nodenn |
20マップ 13リデュース |
20マップ 13リデュース |
脚注 1 9ノード以上
表2-5は、Oracle Big Data Appliance Sun Fire X4270 M2ベース・ラックでのMapReduceサービスのデフォルトのリソース構成を示したものです。
表2-5 Sun Fire X4270 M2ベース・ラックでのマップおよびリデュース・タスクの最大数
| ノード | 6ノード・クラスタ | より大規模なクラスタ脚注 1 |
|---|---|---|
|
Node01とNode02 |
10マップ 6リデュース |
なし |
|
Node03とNode04 |
7マップ 4リデュース |
7マップ 4リデュース |
|
Node05～Nodenn |
15マップ 10リデュース |
15マップ 10リデュース |
脚注 1 9ノード以上
サーバー障害の影響は、CDHクラスタ内におけるサーバーの機能によって異なります。Oracle Big Data Applianceサーバーは、コモディティ・ハードウェアよりも堅牢なため、ハードウェア障害が発生することはほとんどありません。この項では、プライマリ・ラックの様々なサーバー上で実行される重要性の高いサービスに焦点を当てています。完全なリストは、「CDHサービスの実行場所」を参照してください。
クリティカル・ノードは、クラスタが正常に動作し、すべてのサービスをユーザーに提供するために必要です。これとは対照的に、非クリティカル・ノードに障害が発生しても、クラスタはサービスを失うことなく動作し続けます。
シングルラック・クラスタでは、重要なサービスはクラスタの最初の4つのノードに初期インストールされます。残りのノード(node05から最大でnode18まで)は重要性の低いサービスのみを実行します。クリティカル・ノードのいずれかでハードウェア障害が発生した場合は、別の非クリティカル・サーバーにサービスを移行できます。たとえば、node02に障害が発生した場合、重要なサービスをnode05に移行できます。表2-2は、シングル・ラック上に構成されたクラスタのサービスの初期ロケーションを示したものです。
マルチラック・クラスタでは、一部の重要なサービスが第2ラックの第1サーバーで実行されます。「CDHサービスの実行場所」を参照してください。
クリティカル・ノードを移行するには、すべてのクライアントが新しいノードのアドレスで再構成されている必要があります。もう1つの方法としては、障害が発生したサーバーの復旧を待ちます。サービスの喪失とクライアントを再構成する不便さとを比較検討する必要があります。
表2-6 重要なサービスの場所
| ノード名 | 初期ノードの場所 | 重要な機能 |
|---|---|---|
|
第1NameNode |
node01 |
ZooKeeper脚注 1 、第1 NameNode脚注 1、フェイルオーバー・コントローラ脚注 1、バランサ脚注 1、Puppetマスター |
|
第2NameNode |
node02 |
ZooKeeper、第2NameNode、フェイルオーバー・コントローラ、MySQLバックアップ・サーバー |
|
第1 JobTrackerノード |
node03 |
ZooKeeper、第1 JobTracker、フェイルオーバー・コントローラ、Cloudera Managerサーバー、MySQLプライマリ・サーバー |
|
第2 JobTrackerノード |
Node04 |
第2 JobTracker、フェイルオーバー・コントローラ、Oracle Data Integratorエージェント、Hue、Hive、Oozie |
脚注 1 マルチラック・クラスタでは、このサービスは第2ラックの第1サーバー上に初期インストールされます。
NameNodeインスタンスの1つは、初期設定ではnode01上で実行されます。このノードに障害が発生するか、オフライン(再起動など)になると、第2 NameNode (node02)が自動的に引き継いで、クラスタの正常なアクティビティを維持します。
または、第2NameNodeがすでにアクティブな場合は、バックアップなしで動作し続けます。NameNodeが1つのみの場合、クラスタは障害に対して脆弱です。クラスタが、自動フェイルオーバーに必要な冗長性を失うためです。
Puppetマスターもこのノードで実行されます。MammothユーティリティではPuppetを使用するので、たとえばラック内の別の場所にあるディスク・ドライブを交換する必要がある場合、ソフトウェアのインストールまたは再インストールはできません。
|
注意: マルチラック・クラスタでは、NameNodeサービスは第2ラックの第1サーバーにインストールされます。 |
NameNodeインスタンスの1つは、初期設定ではnode02上で実行されます。このノードに障害が発生すると、NameNodeの機能は第1NameNode (node01)にフェイルオーバーされるか、そのままバックアップなしで動作し続けます。ただし、第1NameNodeにも障害が発生すると、クラスタは自動ファイルオーバーに必要な冗長性を失っています。
MySQLバックアップ・データベースもこのノードで実行されます。MySQL Databaseは動作を継続しますが、マスター・データベースのバックアップはありません。
JobTrackerインスタンスの1つは、初期設定ではnode03上で実行されます。このノードに障害が発生するか、このノードが(再起動などによって)オフラインになると、第2 JobTracker (node04)が自動的に機能を引き継ぎ、MapReduceタスクをクラスタの特定のノードへと分配します。
または、第2 JobTrackerがすでにアクティブな場合は、バックアップなしで動作し続けます。JobTrackerが1つのみの場合、クラスタは障害に対して脆弱です。クラスタが、自動フェイルオーバーに必要な冗長性を失うためです。
次のサービスも影響を受けます。
Cloudera Manager: このツールは、CDHクラスタ全体の一元管理機能を提供します。このツールがない場合は、「Hadoop監視ユーティリティの使用方法」で説明したユーティリティを使用すれば、引き続きアクティビティを監視できます。
MySQL Master Database: Cloudera Manager、Oracle Data Integrator、HiveおよびOozieはMySQLデータベースを使用しています。データは自動的にレプリケートされますが、マスター・データベース・サーバーが停止していると、それにはアクセスできません。
JobTrackerインスタンスの1つは、初期設定ではnode04上で実行されます。このノードに障害が発生すると、JobTrackerの機能は第1 JobTracker (node03)にフェイルオーバーされるか、そのままバックアップなしで動作し続けます。ただし、第1 JobTrackerにも障害が発生すると、クラスタは自動フェイルオーバーに必要な冗長性を失っています。
次のサービスも影響を受けます。
Oracle Data Integrator: このサービスは、Oracle Data Integrator Application Adapter for Hadoopをサポートしています。JobTrackerノードが停止している場合、このコネクタは使用できません。
Hive: Hiveは、HDFSに格納されているデータへのSQLライクなインタフェースを備えています。Oracle Big Data Connectorsの多くは、Hive表にアクセスできますが、このノードが動作していない場合は使用できません。
Oozie: このワークフローおよび調整サービスはJobTrackerノードで実行され、このノードがダウンしているときには使用できません。
この項では、Oracle Big Data Applianceを正常に停止して再起動する方法について説明します。
rootアクセス権が必要です。dcliユーティリティを使用できるように、クラスタにパスワードなしSSHが設定されている必要があります。
パスワードなしSSHが設定されていることを確認するには、次の手順を実行します。
クラスタの第1ノードにrootとしてログインします。
dcliコマンドを使用して、コマンドが動作していることを確認します。このコマンドは、クラスタ内のすべてのノードのIPアドレスおよびホスト名を返します。
# dcli -C hostname
192.0.2.1: bda1node01.example.com
192.0.2.2: bda1node02.example.com
.
.
.
これらの結果が得られない場合は、クラスタでdcliを設定します。
# setup-root-ssh -C
|
関連項目: これらのコマンドの詳細は、『Oracle Big Data Applianceオーナーズ・ガイド』を参照してください。 |
次の手順に従って、すべてのOracle Big Data Applianceソフトウェアおよびハードウェア・コンポーネントを停止します。
|
注意: システムが停止すると、次のサービスは自動的に停止します。処理を実行する必要はありません。
|
Cloudera Managerを使用して、Cloudera Managerが管理するサービス(flume、hbase、hdfs、hive、hue、mapreduce、oozieおよびzookeeper)を停止します。
adminユーザーとしてCloudera Managerにログインします。
詳細は、「Cloudera Managerを使用したCDH操作の管理」を参照してください。
開始ページの「Status」ペインで、クラスタのメニューを展開し、「Stop」をクリックした後、確認するように要求されたら「Stop」を再びクリックします。図2-9を参照してください。
このページに移動するには、「Home」タブをクリックし、「Status」サブタブをクリックします。
「Command Details」ページで、すべてのプロセスが停止したら「Close」をクリックします。
Cloudera Management Servicesの同じペインで、mgmtサービスのメニューを展開し、「Stop」をクリックします。
Cloudera Managerからログアウトします。
次の手順に従って、Cloudera Manager Serverを停止します。
Cloudera Managerが実行されているノード(最初はnode03)にrootとしてログインします。
|
注意: 残りのタスクでは、サーバーにrootとしてログインしているとみなされます。dcliコマンドを使用すると、任意のサーバーからコマンドを入力できます。この例では、クラスタ内の任意のノードからnode03でpwdコマンドを実行します。
# dcli -c node03 pwd |
Cloudera Managerサーバーを停止します。
# service cloudera-scm-server stop Stopping cloudera-scm-server: [ OK ]
サーバーが停止したことを確認します。
# service cloudera-scm-server status
cloudera-scm-server is stopped
Cloudera Managerを停止した後、Webコンソールを使用してアクセスすることはできません。
クラスタにOracle Data Integrator Application Adapter for Hadoopがインストールされている場合は、エージェントを停止します。以前にエージェントを起動するために使用したエージェント名およびポート番号を知っている必要があります。デフォルト・エージェント名はOracleDIAgent、デフォルト・ポート番号は20910です。
エージェントのステータスを確認します。
/opt/oracle/odiagent/agent_standalone/oracledi/agent/bin/startcmd.sh OdiPingAgent [-AGENT_NAME=name]
エージェントが実行されている場合は停止します。
/opt/oracle/odiagent/agent_standalone/oracledi/agent/bin/agentstop.sh [-NAME=agent_name] [-PORT=port_number]
すべてのノードがnode03でNFSディレクトリを共有しており、追加のディレクトリが存在する場合もあります。NFSディレクトリ(/opt/exportdir)を含むサーバーを使用できない場合、停止しようとすると他のサーバーがハングします。したがって、まずNFSディレクトリをディスマウントする必要があります。
マウントされているNFSディレクトリを探します。
# dcli -C mount | grep shareddir
192.0.2.1: bda1node03.example.com:/opt/exportdir on /opt/shareddir type nfs (rw,tcp,soft,intr,timeo=10,retrans=10,addr=192.0.2.3)
192.0.2.2: bda1node03.example.com:/opt/exportdir on /opt/shareddir type nfs (rw,tcp,soft,intr,timeo=10,retrans=10,addr=192.0.2.3)
192.0.2.3: /opt/exportdir on /opt/shareddir type none (rw,bind)
.
.
.
サンプル出力は、node03 (192.0.2.3)上の共有ディレクトリを示します。
共有ディレクトリをディスマウントします。
# dcli -C umount /opt/shareddir
カスタムNFSディレクトリをディスマウントします。
Linuxのshutdown -hコマンドは、個別のサーバーの電源を切断します。dcli -gコマンドを使用すると、複数のサーバーを停止できます。
クラスタ内の他のサーバー(つまり、ログインしているサーバーを除く)の名前またはIPアドレスをリストしたファイルを作成します。
他のサーバーを停止します。
# dcli -g filename shutdown -h now
filenameには、手順1で作成したファイルの名前を入力します。
ログインしているサーバーを停止します。
# shutdown -h now
ネットワーク・スイッチを停止するには、データ・センターのPDUまたはブレーカをオフにします。スイッチがオフになるのは、電源を切断した場合のみです。
ネットワーク・スイッチには電源ボタンがありません。停止するのは、電源を切断した場合のみです。
スイッチを停止するには、2つのPDUのすべてのブレーカをオフにします。
次の手順に従って、ハードウェアの電源を投入し、Oracle Big Data Appliance上のすべてのサービスを開始します。
両方のPDUの12個すべてのブレーカのスイッチを入れます。
Oracle ILOMおよびLinuxオペレーティング・システムがサーバーで起動するには4から5分かかります。
パスワードベースのオンディスク暗号化が有効になっている場合は、ログインしてそれらのサーバーのHadoopディレクトリをマウントします。
$ mount-hadoop-dirs Enter password to mount Hadoop directories: password
サーバーが自動的に起動しない場合は、サーバーの前面にある電源ボタンを押してローカルで起動するか、またはOracle ILOMを使用してリモートで起動できます。Oracle ILOMには、コマンドライン・インタフェース(CLI)やWebコンソールなど、複数のインタフェースがあります。必要なインタフェースを使用します。
たとえば、rootとしてWebインタフェースにログインし、「Remote Power Control」ページからサーバーを起動できます。Oracle ILOMのURLはホストのものと同じですが、通常は-cまたは-ilom拡張子が付いている点が異なります。このURLはbda1node4のOracle ILOMに接続します。
http://bda1node04-ilom.example.com
Cloudera Managerが制御するすべてのHDFSサービスを開始するには、Cloudera Managerを使用します。
Cloudera Managerが実行されているノード(最初はnode03)にrootとしてログインします。
|
注意: 残りのタスクでは、サーバーにrootとしてログインしているとみなされます。dcliコマンドを使用すると、任意のサーバーからコマンドを入力できます。この例では、クラスタ内の任意のノードからnode03でpwdコマンドを実行します。
# dcli -c node03 pwd |
Cloudera Managerがnode03で自動的に起動したことを確認します。
# service cloudera-scm-server status cloudera-scm-server (pid 11399) is running...
実行されていない場合は、起動します。
# service cloudera-scm-server start
adminユーザーとしてCloudera Managerにログインします。
詳細は、「Cloudera Managerを使用したCDH操作の管理」を参照してください。
開始ページの「Status」ペインで、クラスタのメニューを展開し、「Start」をクリックした後、確認するように要求されたら「Start」を再びクリックします。図2-9を参照してください。
このページに移動するには、「Home」タブをクリックし、「Status」サブタブをクリックします。
「Command Details」ページで、すべてのプロセスが開始されたら「Close」をクリックします。
Cloudera Management Servicesの同じペインで、mgmtサービスのメニューを展開し、「Start」をクリックします。
Cloudera Managerからログアウトします(オプション)。
このクラスタでOracle Data Integrator Application Adapter for Hadoopが使用されている場合は、エージェントを起動します。
エージェントのステータスを確認します。
# /opt/oracle/odiagent/agent_standalone/oracledi/agent/bin/startcmd.sh OdiPingAgent [-AGENT_NAME=agent_name]
エージェントを起動します。
# /opt/oracle/odiagent/agent_standalone/oracledi/agent/bin/agent.sh [-NAME=agent_name] [-PORT=port_number]
Oracle Big Data Applianceではソフトウェアやデータの不正利用を防ぐための予防策を取ることができます。
Oracle Big Data Applianceにインストールされるオープンソース・パッケージごとに、1つ以上のユーザーおよびグループが作成されます。このようなユーザーのほとんどは、ログイン権限、シェル、またはホーム・ディレクトリを持っていません。これらはデーモンによって使用され、各ユーザー向けのインタフェースとしては設計されていません。たとえば、Hadoopはhdfsユーザーとして、MapReduceはmapredとして、Hiveはhiveとしてそれぞれ動作します。
Oracle Big Data Applianceソフトウェアのインストール直後にHadoopおよびHiveジョブを実行するには、oracle IDを使用できます。このユーザー・アカウントは、ログイン権限、シェル、およびホーム・ディレクトリを保持しています。
Oracle NoSQL DatabaseおよびOracle Data Integratorはoracleユーザーとして実行します。プライマリ・グループはoinstallです。
|
注意: インストール時に作成されたユーザーは、ソフトウェアの操作に必要なため、削除、再作成および変更はしないでください。 |
表2-7に、Oracle Big Data Applianceソフトウェアのインストール時に自動的に作成され、CDHコンポーネントおよびその他のソフトウェア・パッケージによって使用されるオペレーティング・システム・ユーザーおよびグループを示します。
表2-7 オペレーティング・システム・ユーザーおよびグループ
| ユーザー名 | グループ | 使用者 | ログイン権限 |
|---|---|---|---|
|
|
Flume NG親およびノード |
なし |
|
|
|
HBaseプロセス |
なし |
|
|
|
なし |
||
|
|
なし |
||
|
|
Hueプロセス |
なし |
|
|
|
JobTracker、TaskTracker、Hive Thriftデーモン |
あり |
|
|
|
|
あり |
|
|
|
Oozieサーバー |
なし |
|
|
Oracle NoSQL Database、Oracle Loader for Hadoop、Oracle Data IntegratorおよびOracle DBA |
あり |
||
|
|
Puppet親( |
なし |
|
|
|
Sqoopメタストア |
なし |
|
|
自動サービス・リクエスト |
なし |
||
|
|
ZooKeeperプロセス |
なし |
Oracle Big Data Applianceは、ソフトウェア・インストールのオプションとしてKerberosセキュリティをサポートしています。Kerberosで保護されているクラスタにアクセスするためのクライアントとユーザーの設定の詳細は、第3章を参照してください。
Hadoop上の通常の認可モデルはHDFSファイル・レベルであり、ユーザーはファイル内のすべてのデータへのアクセス権を持っているか、またはまったく持っていないかのどちらかです。対照的に、Apache SentryはHiveおよびImpala SQL問合せエンジンと統合され、Hadoopに格納されているデータに対するファイングレイン認証の機能を備えています。
Mammothユーティリティ・バージョン2.5より、Oracle Big Data Applianceは、ソフトウェアのインストール中にSentryを自動的に構成します。
|
関連項目:
|
オンディスク暗号化は、ディスクにあるデータを保護します。オンディスク暗号化が有効になっている場合、Oracle Big Data Applianceはディスクに格納されているデータを自動的に暗号化および復号化します。オンディスク暗号化は、パフォーマンスに若干影響する可能性はありますが、Hadoopデータへのユーザー・アクセスには影響しません。
Oracle Big Data Applianceでは2つのタイプのオンディスク暗号化をサポートしています。
Password-based encryption: パスワードに基づいてHadoopデータを暗号化します。パスワードは、1つのクラスタ内のすべてのサーバーで同じです。mammoth-reconfig updateコマンドを使用すると、いつでもパスワードを変更できます。詳細は、『Oracle Big Data Applianceオーナーズ・ガイド』を参照してください。
サーバーからディスクを削除した場合、サーバー(同じサーバーまたは異なるサーバー)にディスクをインストールし、サーバーを起動してパスワードを指定するまで暗号化されたデータは引き続き保護されます。サーバーの電源が切断され、Oracle Big Data Applianceラックから取り外された場合、サーバーを再起動してパスワードを指定するまで暗号化されたデータは引き続き保護されます。すべてのサーバーが起動された後、パスワードを入力してデータへのアクセスを有効にする必要があります。「Oracle Big Data Applianceの起動」を参照してください。
TPM encryption: サーバーのマザーボード上のTrusted Platform Module (TPM)チップを使用してHadoopデータを暗号化します。サーバーからディスクを削除した場合、同じサーバーにディスクを再インストールするまでデータは読み取れません。Oracle Big Data Applianceラックからサーバーを取り外した場合、データには引き続きアクセスできます。ディスクが同じサーバー上にあるかぎり、データは正常に使用できるように自動的に暗号化および復号化されます。
オンディスク暗号化は、Mammothユーティリティによる初期インストール時に選択できるオプションです。mammoth-reconfigまたはbdacliユーティリティを使用して、いつでもオンディスク暗号化を有効または無効にすることもできます。
|
関連項目: 『Oracle Big Data Applianceオーナーズ・ガイド』 |
表2-8に、CDH用のポート番号の他に使用される可能性のあるポート番号を示します。
特定のサーバー上で使用されるポート番号を確認するには、次の手順を実行します。
Cloudera Managerで、ページ上部にある「Hosts」タブをクリックして、「Hosts」ページを表示します。
「Name」列でサーバーのリンクをクリックすると、その詳細ページが表示されます。
「Ports」セクションまで下方向にスクロールします。
|
関連項目: CDHのポート番号の詳細なリストは、次に示すClouderaのWebサイトを参照してください。 |
Puppetノード・サービス(puppetd)は、すべてのサーバー上でrootとして継続的に実行されます。Puppetマスターに対する更新リクエストのトリガーとなるキック・リクエストを、ポート8139上でリスニングします。このポート上で更新は受信しません。
Puppetマスター・サービス(puppetmasterd)は、Oracle Big Data Applianceのプライマリ・ラックの第1サーバー上で、Puppetユーザーとして継続的に実行されます。ポート8140上で、Puppetノードに更新をプッシュするリクエストをリスニングします。
Puppetノードは、ソフトウェアのインストール時に初期登録するため、証明書を生成してPuppetマスターに送信します。ソフトウェアのアップデートの場合は、PuppetマスターからPuppetノードに信号(キック)が送信され、そこから登録先のPuppetマスター・ノードに対して、すべての構成変更がリクエストされます。
Puppetマスターは、既知の有効な証明書を保持しているPuppetノードに対してのみ更新を送信します。Puppetノードは、初期登録されたPuppetマスターのホスト名からの更新のみを受け付けます。Oracle Big Data Applianceでは、ラック内の通信に内部ネットワークを使用するため、Puppetマスターのホスト名は、/etc/hostsを使用して、内部のプライベートIPアドレスに解決されます。
Oracle Audit Vault and Database Firewallを使用して、Oracle Big Data ApplianceでHDFSとMapReduceの監査証跡を作成し、監視できます。
この項では、Oracle Big Data Applianceのプラグインについて次の内容を説明します。
Oracle Audit Vault and Database Firewallは、データベースや、ITインフラストラクチャで重要なその他のコンポーネントを、主として次のような形で保護します。
企業の監査プラットフォームを統合します。
Oracle Database、Oracle Big Data Appliance、オペレーティング・システム、ディレクトリ、ファイル・システムなどにおけるアクティビティを取得します。
企業全体のアクティビティを把握できるように、監査情報を単一のレポート・フレームワークで使用可能にします。各システムを個々に監視する必要はなく、コンピュータ・インフラストラクチャを全体として確認できます。
Audit Vault Serverには、管理者と監査者の両方が使用できるWebベースのグラフィカル・ユーザー・インタフェースがあります。
Oracle Big Data ApplianceでCDH/Hadoopクラスタをセキュア・ターゲットとして構成できます。Oracle Big Data ApplianceのAudit Vaultプラグインは、次のサービスから監査データとロギング・データを収集します。
MapReduce: ファイル・アクセスに対応するMapReduceジョブを誰が実行するか。
Hive DDL: Hiveデータベースを誰が変更するか。
Oozieワークフロー: 誰がワークフロー・アクティビティを実行するか。
Audit Vaultプラグインは、オプションとしてインストールされます。Mammothユーティリティは、ソフトウェア・インストール・プロセスの一部としてOracle Big Data Applianceでの監視を自動的に構成します。
|
関連項目: Oracle Audit Vault and Database Firewallの詳細は、次を参照してください。 |
プラグインの設定に必要な手順はすべて、ユーザーが指定した情報を使用してOracle Big Data ApplianceのMammothユーティリティが実行します。
Oracle Big Data Appliance用のAudit Vaultプラグインを設定するには、次の手順を実行します。
Oracle Big Data Applianceと同じネットワーク上で、Oracle Audit Vault and Database Firewall Serverリリース12.1.1が稼働していることを確認します。
|
関連項目: 『Oracle Audit Vault and Database Firewallインストレーション・ガイド』 |
Oracle Big Data Appliance構成生成ユーティリティの「Audit Vault Plug-in」セクションをすべて指定します。
Mammothユーティリティを使用して、Oracle Big Data Applianceソフトウェアをインストールします。このステップは通常、オラクル社の担当者が実行します。
ソフトウェアのインストールが完了するとOracle Big Data ApplianceにAudit Vaultプラグインがインストールされ、Oracle Audit Vault and Database Firewallがその監査情報を収集します。他のインストール手順を実行する必要はありません。
|
関連項目: Oracle Big Data Appliance構成生成ユーティリティの使用方法の詳細は、『Oracle Big Data Applianceオーナーズ・ガイド』を参照してください。 |
プラグインのインストールが終わると、他のセキュア・ターゲットと同様にOracle Big Data Applianceを監視できるようになります。Audit Vault Serverは、アクティビティ・レポートを自動的に収集します。
次の手順では、あるタイプの監視アクティビティについて説明します。
Oracle Big Data Applianceのアクティビティ・レポートを表示するには、次の手順を実行します。
Audit Vault Serverに監査者としてログインします。
「Reports」タブをクリックします。
「Built-in Reports」で、「Audit Reports」をクリックします。
すべてのアクティビティを参照するには、「Activity Reports」リストで「All Activity」のBrowse report dataアイコンをクリックします。
イベントをリストするフィルタを追加または削除します。
イベント名には、ACCESS、CREATE、DELETEおよびOPENがあります。
最初の列にあるSingle row viewアイコンをクリックして、詳細レポートを表示します。
図2-10に、アクティビティ・レポートの冒頭を示します。これには、Hadoopシーケンス・ファイルへのアクセスが記録されています。
|
関連項目: Oracle Audit Vault and Database Firewall監査者ガイド |
CDHの問題のトラブルシューティングを行うために、Oracleサポートのアドバイスが必要な場合は、まずbdadiagユーティリティをcmオプションを指定して使用し、診断情報を収集してください。
診断情報を収集するには、次の手順を実行します。
Oracle Big Data Applianceサーバーにrootとしてログインします。
少なくともcmオプションを指定してbdadiagを実行します。必要に応じてコマンドに他のオプションを含めることができます。bdadiagの構文の詳細は、『Oracle Big Data Applianceオーナーズ・ガイド』を参照してください。
# bdadiag cm
コマンド出力によって、診断ファイルの名前と場所が識別されます。
My Oracle Support (http://support.oracle.com)へ移動します。
サービス・リクエスト(SR)を開きます(まだ開いていない場合)。
SRにbz2ファイルをアップロードします。ファイルのサイズが大きすぎる場合は、sftp.oracle.comにアップロードしてください(次の手順を参照)。
診断情報をftp.oracle.comにアップロードするには、次の手順を実行します。
SFTPクライアントを開き、sftp.oracle.comに接続します。ポート2021とリモート・ディレクトリ/support/incoming/targetを指定します(targetは、Oracle Supportにより指定されたフォルダ名です)。
コマンドラインSFTPクライアントを使用している場合は、例2-1を参照してください。
Oracle Single Sign-Onのアカウントとパスワードでログインします。
診断ファイルを新しいディレクトリにアップロードします。
このフル・パスおよびファイル名でSRを更新します。
例2-1は、SFTPコマンド・インタフェースを使用して、診断情報をアップロードするコマンドを示しています。
例2-1 FTPを使用した診断情報のアップロード
$ sftp -o port=2021 my.user.name@oracle.com@sftp.oracle.com Connecting to sftp.oracle.com... . . . Enter password for my.user.name@oracle.com Password: password sftp> cd support/incoming/SR123456 sftp> put /tmp/bdadiag_bda1node01_1216FM5497_2013_07_18_07_33.tar.bz2 Uploading bdadiag_bda1node01_1216FM5497_2013_07_18_07_33.tar.bz2 to //support/incoming/create_table.sql bdadiag_bda1node01_1216FM5497_2013_07_18_07_33.tar.bz2 to support/incoming/create_table.sql 100% 311 0.3KB/s 00:00 sftp> exit $
