2 Oracle Big Data Applianceの管理

この章では、Oracle Big Data Applianceにインストールされるソフトウェアおよびサービスについて説明します。次の項について説明します。

• Oracle Enterprise Managerを使用した複数のクラスタの監視

• Cloudera Managerを使用した操作の管理

• Hadoop監視ユーティリティの使用方法

• Cloudera Hueを使用したHadoopの操作

• Oracle Big Data Applianceソフトウェアについて

• CDHクラスタについて

• ソフトウェアの可用性に与えるハードウェアの影響

• ハードウェア障害の管理

• Oracle Big Data Applianceの停止および起動

• Oracle Big Data SQLの管理

• Oracle Big Data Applianceのセキュリティ

• Oracle Big Data Applianceの監査

• オラクル社カスタマ・サポートに提供する診断情報の収集

2.1 Oracle Enterprise Managerを使用した複数のクラスタの監視

Oracle Enterprise Managerプラグインでは、Oracle Exadata Database Machineや他のOracle Databaseインストールに使用するのと同じシステム監視ツールをOracle Big Data Applianceに使用できます。プラグインを使用して、インストールされたソフトウェア・コンポーネントのステータスを表や図式を使用した形式で表示したり、これらのソフトウェア・サービスの起動や停止を行えます。ネットワークおよびラック・コンポーネントの状態を監視することもできます。

Oracle Enterprise Managerを使用すると、同じインフィニバンド・ファブリック上のすべてのOracle Big Data Applianceラックを監視できます。ラック・ハードウェアと論理クラスタのソフトウェア・レイアウトの両方のサマリー・ビューが用意されています。

注意:

開始する前に、Oracle SupportにEnterprise Managerプラグイン機能に関する最新情報についてお問い合せください。

2.1.1 Enterprise Manager Webインタフェースの使用

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の「YARN」ページ

「図2-1 Oracle Enterprise Managerの「YARN」ページ」の説明

Oracle Enterprise Managerを使用してOracle Big Data Applianceを監視するには、次の手順を実行します。

1. プラグインをダウンロードしてインストールします。『Oracle Enterprise Manager System Monitoring Plug-inインストレーション・ガイドfor Oracle Big Data Appliance』を参照してください。

2. 管理ユーザーとしてOracle Enterprise Managerにログインします。

3. 「ターゲット」メニューから「ビッグ・データ・アプライアンス」を選択し、ビッグ・データ・ページを表示します。Oracle Enterprise Managerによって検出済のターゲットの全体的なステータスが表示されます。

4. 詳細ページを表示するターゲット・クラスタを選択します。

5. ターゲット・ナビゲーション・ツリーを展開し、コンポーネントを表示します。すべてのレベルで情報を使用可能です。

6. ツリーでコンポーネントを選択し、ホーム・ページを表示します。

7. 表示を変更するには、メイン表示領域の左上部にあるドロップダウン・メニューから項目を選択します。

2.1.2 Enterprise Managerコマンドライン・インタフェースの使用

Enterprise Managerコマンドライン・インタフェース(emcli)はOracle Big Data Applianceに、他のすべてのソフトウェアとともにインストールされます。このインタフェースは、Webインタフェースと同じように機能します。Oracle Management Serverに接続するための資格証明を入力する必要があります。

ヘルプを表示するには、emcli helpと入力してください。

関連項目:

『Oracle Enterprise Managerコマンドライン・インタフェース・ガイド』

2.2 Cloudera 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は、ResourceManagerノード(node03)上で動作し、ポート7180上で使用できます。

Cloudera Managerを使用するには、次の手順を実行します。

1. ブラウザを開き、次のようにURLを入力します。

   この例で、bda1はアプライアンス名、node03はサーバー名、example.comはドメイン、7180はデフォルトのポート番号(それぞれCloudera Managerで使用)を示します。

2. Cloudera Managerのユーザー名とパスワードでログインします。設定を変更できるのは、管理者権限を持つユーザーのみです。その他のCloudera Managerユーザーは、Oracle Big Data Applianceのステータスを表示できます。

関連項目:

https://www.cloudera.com/documentation/enterprise/latest/topics/cm_dg_about.htmlにClouderaの監視および診断情報についての詳細が示されています。

2.2.1 Oracle Big Data Applianceのステータスの監視

Cloudera Managerでは、画面上部のメニュー・バーから、次に示す任意のページを選択できます。

• Home: アクティビティの概要をグラフィカルに表示し、Cloudera Managerによって制御されているすべてのサービスにリンクします。次の図を参照してください。

• Clusters: 複数のクラスタ上のサービスにアクセスします。

• Hosts: クラスタのすべてのサーバーの状態、ディスク使用量、負荷、物理メモリー、スワップ領域などの統計情報を監視します。

• Diagnostics: イベントおよびログにアクセスします。Cloudera Managerは、システムとサービスに関する履歴情報を収集します。選択したサーバー、サービス、および期間を対象に、特定の句を検索できます。また、ログ・メッセージの最小重大度(TRACE、DEBUG、INFO、WARN、ERRORまたはFATAL)を選択して、検索に含めることもできます。

• Audits: 選択した時間範囲の監査履歴ログを表示します。ユーザー名、サービスまたはその他の条件によって結果を絞り込み、CSVファイルとしてログをダウンロードできます。

• Charts: Cloudera Managerの時系列データ・ストアから各種のグラフ・タイプ(折れ線グラフ、棒グラフなど)でメトリックを表示できます。

• Backup: スナップショット・ポリシーおよびスケジュール済のレプリケーションにアクセスします。

• Administration: 「Settings」、「Alerts」、「Users」、「Kerberos」など各種の管理オプションを提供します。

次の図に、Cloudera Managerのホームページを示します。

図2-2 Cloudera Managerのホームページ

「図2-2 Cloudera Managerのホームページ」の説明

2.2.2 管理タスクの実行

Cloudera Manager管理者は、Oracle Big Data Applianceの状態や使用状況を監視するための様々なプロパティの変更、ユーザーの追加、およびKerberosセキュリティの設定を行うことができます。

Cloudera Manager Administrationにアクセスするには、次の手順を実行します。

1. 管理者権限でCloudera Managerにログインします。

2. 「Administration」をクリックし、メニューからタスクを選択します。

2.2.3 Cloudera Managerを使用したCDHサービスの管理

Cloudera Managerは次のサービスを管理するインタフェースを備えています。

• HDFS

• Hive

• Hue

• Oozie

• YARN

• ZooKeeper

Cloudera Managerを使用すると、これらのサービスの設定変更、停止および再開を行うことができます。追加のサービスも使用できますが、使用する前に構成が必要です。「未構成のソフトウェア」を参照してください。

注意:

Linuxサービス・スクリプトやHadoop構成ファイルを手動で編集しても、これらのサービスには何の効果もありません。これらを管理および構成するには、Cloudera Managerを使用する必要があります。

2.3 Hadoop監視ユーティリティの使用方法

ネイティブのHadoopユーティリティを使用することもできます。これらのユーティリティは読取り専用であり、認証を必要としません。

Cloudera Managerでは、これらのユーティリティの正しいURLを簡単に取得できます。「YARN」サービス・ページで、「Web UI」サブメニューを展開します。

2.3.1 MapReduceジョブの監視

リソース・マネージャのインタフェースを使用してMapReduceジョブを監視できます。

MapReduceジョブを監視するには、次の手順を実行します。

• ブラウザを開き、次のようにURLを入力します。

  http://bda1node03.example.com:8088

  この例では、bda1はラックの名前、node03はYARNリソース・マネージャが実行されているサーバーの名前、8088はユーザー・インタフェースのデフォルトのポート番号です。

次の図に、リソース・マネージャのインタフェースを示します。

図2-3 YARNリソース・マネージャのインタフェース

「図2-3 YARNリソース・マネージャのインタフェース」の説明

2.3.2 HDFSの状態の監視

クラスタの最初の2つのノードでDFS状態ユーティリティを使用することで、Hadoopファイル・システムの状態を監視できます。

HDFSを監視するには、次の手順を実行します。

• ブラウザを開き、次のようにURLを入力します。

  http://bda1node01.example.com:50070

  この例では、bda1はラックの名前、node01はdfshealthユーティリティが実行されているサーバーの名前、50070はユーザー・インタフェースのデフォルトのポート番号です。

図2-3に、DFS状態ユーティリティのインタフェースを示します。

図2-4 DFS状態ユーティリティ

「図2-4 DFS状態ユーティリティ」の説明

2.4 Cloudera Hueを使用したHadoopの操作

Hueはブラウザで動作し、複数のアプリケーションに使いやすいインタフェースを提供して、HadoopとHDFSの操作をサポートします。Hueを使用すると、次のタスクを実行できます。

• Hiveデータ・ストアの問合せ

• Hive表の作成、ロードおよび削除

• HDFSファイルおよびディレクトリの操作

• MapReduceジョブの作成、発行および監視

• MapReduceジョブの監視

• Oozieダッシュボードを使用したワークフローの作成、編集および発行

• ユーザーおよびグループの管理

Hueは、Oracle Big Data Applianceに自動的にインストールおよび構成されます。ResourceManagerノードのポート8888上で動作します。各種のクラスタ構成内でのHueの場所については、「CDHクラスタについて」の表を参照してください。

Hueを使用するには、次の手順を実行します。

1. Cloudera Managerにログインし、「Home」ページのhueサービスをクリックします。

2. クイック・リンクの下にあるhueページで、「Hue Web UI」をクリックします。

3. ブラウザでHueを直接開けるように、HueのURLをブックマークします。次にURLの例を示します。

   http://bda1node03.example.com:8888

4. Hue資格証明を使用してログインします。

   Hueアカウントがまだ作成されていない場合は、次の資格証明を使用してデフォルトのHue管理者アカウントにログインします。

   • ユーザー名: admin

   • パスワード: cm-admin-password

   ここで、cm-admin-passwordは、Cloudera Manager管理ユーザーのクラスタがアクティブ化されたときに指定されたパスワードです。この後で、他のユーザーと管理者アカウントを作成できます。

次の図に、Hive Query Editorを示します。

図2-5 Hive Query Editor

「図2-5 Hive Query Editor」の説明

関連項目:

Hueユーザー・ガイドの場所

https://www.cloudera.com/documentation/enterprise/5-15-x/topics/hue.html

2.5 Oracle Big Data Applianceソフトウェアについて

次の各項では、Oracle Big Data Applianceにインストールされるソフトウェアについて説明します。

この項の内容は次のとおりです。

• ソフトウェア・コンポーネント

• 未構成のソフトウェア

• サービス間でのリソースの割当て

2.5.1 ソフトウェア・コンポーネント

主要なソフトウェア・コンポーネントおよびバージョンのリストについては、このガイドの「Oracle Big Data Applianceリリース4.13での変更点」を参照してください。

これらのソフトウェア・コンポーネントは、クラスタのすべてのサーバーにインストールされます。Oracle Linux、必須ドライバ、ファームウェアおよびハードウェア検証ユーティリティは工場出荷時にインストール済です。その他のソフトウェアは、すべてサイトにインストールします。オプションのソフトウェア・コンポーネントは、インストールで構成されない場合があります。

次の図は、主要コンポーネント間の関係を示しています。

図2-6 Oracle Big Data Applianceの主要ソフトウェア・コンポーネント

「図2-6 Oracle Big Data Applianceの主要ソフトウェア・コンポーネント」

ファームウェア

ファームウェアの最新情報については、My Oracle Support My Oracle Supportで次のドキュメントを参照してください。

• Doc ID 1542871.1 - Oracle Big Data ApplianceにおけるBDAソフトウェア管理コンポーネントのファームウェア使用状況およびアップグレード情報

• Doc ID 1528190.1 - Oracle Big Data Appliance Sun Fire X4270 M2、X3-2、X4-2およびX5-2のファームウェア・アップグレード・ポリシーおよび工場出荷バージョン

関連項目:

Mammothユーティリティの詳細は、『Oracle Big Data Applianceオーナーズ・ガイド』を参照してください。

追加のソフトウェアをインストールする場合は、Oracle Big Data Applianceのライセンス情報ユーザー・マニュアルに記載されているガイドラインに従ってください。

2.5.2 未構成のソフトウェア

ご使用のOracle Big Data Applianceライセンスには、Cloudera Enterprise Data Hub Editionのすべてのコンポーネントが含まれています。すべてのCDHコンポーネントは、Mammothユーティリティによって自動的にインストールされます。これらは、Cloudera Webサイトからはダウンロードしないでください。

ただし、次のような一部のサービスは、使用前にCloudera Managerを使用して追加する必要があります。

• Apache Flume

• Apache HBase

• Apache Spark

• Apache Sqoop

• Cloudera Impala

• Cloudera Search

サービスを追加するには、次の手順を実行します。

1. adminユーザーとしてCloudera Managerにログインします。

2. 「Home」ページで、左側のパネルのクラスタ・メニューを展開し、「Add a Service」を選択して「Add Service」ウィザードを開きます。最初のページには、追加できるサービスがリストされます。

3. ウィザードのステップに従います。

関連項目:

• CDHコンポーネントのリストは、次を参照してください。

  http://www.cloudera.com/content/www/en-us/products/apache-hadoop/key-cdh-components.html

2.5.3 サービス間でのリソースの割当て

リソース・プールの合計の割合として、リソースをHDFS、YARN、Oracle Big Data SQL、Hiveなどの各サービスに割り当てることができます。Cloudera Managerでは、これらの割合に基づいて推奨されるリソース管理設定が自動的に計算されます。あるサービスに対する高負荷が他のサービスに与える影響が制限されるように、静的サービス・プールはクラスタ上のサービスを切り離します。

サービス間にリソースを割り当てるには、次の手順を実行します。

1. adminとしてCloudera Managerにログインします。

2. ページの上部の「Clusters」メニューを開き、「Resource Management」の下の「Static Service Pools」を選択します。

3. 「Configuration」を選択します。

4. ウィザードのステップに従うか、または「Change Settings Directly」をクリックして現在の設定を変更します。

2.6 CDHクラスタについて

すべてのサービスはCDHクラスタ内の全ノード上にインストールされますが、個々のサービスは指定されたノードでのみ実行されます。サービスの場所は、クラスタの構成によって多少異なります。

この項では、デフォルトのYARN構成のサービスについて説明します。

この項の内容は次のとおりです。

• シングルラックCDHクラスタ上でサービスが実行される場所

• マルチラックCDHクラスタ上でサービスが実行される場所

• About MapReduce

• NameNodeの自動フェイルオーバー

• ResourceManagerの自動フェイルオーバー

2.6.1 3ノードCDHクラスタ上でサービスが実行される場所

Oracle Big Data Applianceは、開発目的で3ノード・クラスタを使用できます。

注意:

3ノード・クラスタは、すべてのノードがマスター・ノードであるため、一般に本番環境には適していません。これにより、高可用性に制約が課されます。本番環境でお薦めされる最小のクラスタ・サイズは5ノードです。

表2-1に、3ノード開発クラスタのサービス・ロケーションを示します。

Node1	Node2	Node3
NameNode	NameNode/Failover	-
Failover Controller	Failover Controller	-
DataNode	DataNode	DataNode
NodeManager	NodeManager	NodeManager
JournalNode	JournalNode	JournalNode
-	HttpFS	Cloudera ManagerおよびCMロール
-	MySQL Backup	MySQL Primary
ResourceManager	-	ResourceManager
	-	JobHistory
-	ODI	Spark History
-	Oozie	-
Hueサーバー	Hueサーバー	-
Hueロード・バランサ	Hueロード・バランサ	-
ZooKeeper	ZooKeeper	ZooKeeper
アクティブNavigator Key Trustee Server (HDFS透過的暗号化が有効化されている場合)	パッシブNavigator Key Trustee Server (HDFS透過的暗号化が有効化されている場合)	-
KerberosマスターKDC (MIT Kerberosが有効化され、BDA上のKDCが使用されている場合のみ)	KerberosスレーブKDC (MIT Kerberosが有効化され、BDA上のKDCが使用されている場合のみ)	-
Sentry Server(有効化されている場合)	Sentry Server(有効化されている場合)	-
Hive Metastore	Hive Metastore	-
-	WebHCat	-

2.6.2 シングルラックCDHクラスタ上でサービスが実行される場所

表2-2は、シングル・ラック内に構成されたCDHクラスタ内のサービスを示したものです(5つ以上のノードを使用したスタータ・ラックやクラスタを含む)。Node01はクラスタ内の最初のサーバー(サーバー1、7または10)で、nodennはクラスタ内の最後のサーバー(サーバー6、9、12または18)です。マルチラック・クラスタには、開発目的の場合の3ノード・クラスタと同様、様々なサービス・レイアウトがあります。この章では、どちらも個別に説明します。

表2-2 シングル・ラック内にある1つ以上のCDHクラスタのサービス・ロケーション

node01	node02	node03	Node04	Node05 - nn
バランサ	-	Cloudera Manager Server	-	-
Cloudera Manager Agent	Cloudera Manager Agent	Cloudera Manager Agent	Cloudera Manager Agent	Cloudera Manager Agent
DataNode	DataNode	DataNode	DataNode	DataNode
Failover Controller	Failover Controller	-	Oozie	-
JournalNode	JournalNode	JournalNode	-	-
-	MySQL Backup	MySQL Primary	-	-
NameNode	NameNode	Navigator監視サーバーおよびNavigatorメタデータ・サーバー	-	-
NodeManager (8ノード以下のクラスタ内)	NodeManager (8ノード以下のクラスタ内)	NodeManager	NodeManager	NodeManager
-	-	SparkHistoryServer	Oracle Data Integratorエージェント	-
-	-	ResourceManager	ResourceManager	-
ZooKeeper	ZooKeeper	ZooKeeper	-	-
Big Data SQL(有効化されている場合)	Big Data SQL(有効化されている場合)	Big Data SQL(有効化されている場合)	Big Data SQL(有効化されている場合)	Big Data SQL(有効化されている場合)
Kerberos KDC (MIT Kerberosが有効化され、BDA上のKDCが使用されている場合)	Kerberos KDC (MIT Kerberosが有効化され、BDA上のKDCが使用されている場合)	JobHistory	-	-
Sentry Server(有効化されている場合)	Sentry Server(有効化されている場合)	-	-	-
Hive Metastore	-	-	Hive Metastore	-
アクティブNavigator Key Trustee Server (HDFS透過的暗号化が有効化されている場合)	パッシブNavigator Key Trustee Server (HDFS透過的暗号化が有効化されている場合)	-	-	-
-	HttpFS	-	-	-
Hueサーバー	-	-	Hueサーバー	-
Hueロード・バランサ	-	-	Hueロード・バランサ	-

注意:

Oracle Big Data Discoveryがインストールされている場合、プライマリ・クラスタのNode05上のNodeManagerおよびDataNodeはデコミッションされます。

Oozie高可用性が有効化されている場合、Node04および顧客が選択した別のノード(ResourceNodeが望ましい)上にOozieサーバーがホストされます。

2.6.3 マルチラックCDHクラスタ上でサービスが実行される場所

複数のラックが単一のCDHクラスタとして構成される場合、いくつかの重要なサービスが第2ラックにインストールされます。異なるマルチラック・クラスタでは、最初のラックと第2ラックのサービスの分散に違いがある場合があります。これらの違いの原因となるシナリオは、次の2つです。

• クラスタが、元の構成で複数のラックにまたがっていました。

  結果として得られる最初と第2のラックに対するサービス・ロケーションを、表2-3と表2-4に示します。この場合、JournalNode、Mysql Primary、ResourceManagerおよびZookeeperは、最初のラックのノード2にインストールされます。

• クラスタは、元の構成でシングルラックでしたが、その後拡張されました。

  結果として得られる最初と第2のラックに対するサービス・ロケーションを、表2-5と表2-6に示します。この場合、JournalNode、Mysql Primary、ResourceManagerおよびZookeeperは、最初のラックのノード3にインストールされます。

注意:

Oracle Big Data Discoveryがインストールされている場合、プライマリ・クラスタの最初のラックにおけるNode05上のNodeManagerおよびDataNodeはデコミッションされます。

特にクラスタ・サイズによる違いとして、8ノード以下のクラスタの場合、NameNodeが実行されるノードではNodeManagerも実行されます。これは、8ノードを超えるクラスタには該当しません。

表2-3 最初のラックのサービス・ロケーション(クラスタがマルチラック・クラスタとして開始した場合)

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	-	-	-	-
JournalNode	JournalNode	Navigator監視サーバーおよびNavigatorメタデータ・サーバー	-	-
NameNode	MySQL Primary	SparkHistoryServer	-	-
NodeManager (8ノード以下のクラスタ内)	NodeManager	NodeManager	NodeManager	NodeManager
–	ResourceManager	-	-	-
ZooKeeper	ZooKeeper	-	-	-
Kerberos KDC (MIT Kerberosが有効化され、BDA上のKDCが使用されている場合のみ)	Kerberos KDC (MIT Kerberosが有効化され、BDA上のKDCが使用されている場合のみ)	-	-	-
Sentry Server(有効化されている場合)	Sentry Server(有効化されている場合)	-	-	-
Hiveメタストア(もう一方のHiveメタストア・サービスが第2ラックの2番目のノードにあります)	-	-	-	-
Big Data SQL(有効化されている場合)	Big Data SQL(有効化されている場合)	Big Data SQL(有効化されている場合)	Big Data SQL(有効化されている場合)	Big Data SQL(有効化されている場合)
アクティブNavigator Key Trustee Server (HDFS透過的暗号化が有効化されている場合)	-	-	-	-
Hueサーバー	-	-	Hueサーバー	- -
Hueロード・バランサ	-	-	Hueロード・バランサ

^脚注 1 nnには追加ラック内のサーバーが含まれます。

表2-4に、当初、複数のラックにまたがって構成されたクラスタの第2ラックにおけるサービス・ロケーションを示します。

表2-4 第2ラックのサービス・ロケーション(クラスタがマルチラック・クラスタとして開始した場合)

node01	node02	node03	Node04	Node05 - nn
バランサ	-	-	-	-
Cloudera Manager Agent	Cloudera Manager Agent	Cloudera Manager Agent	Cloudera Manager Agent	Cloudera Manager Agent
DataNode	DataNode	DataNode	DataNode	DataNode
Failover Controller	-	-	-	-
JournalNode	Oozie	-	-	-
MySQL Backup	-	-	-	-
NameNode	-	-	-	-
NodeManager (8ノード以下のクラスタ内)	NodeManager	NodeManager	NodeManager	NodeManager
HttpFS	Oracle Data Integratorエージェント	-	-	-
-	ResourceManager	-	-	-
ZooKeeper	-	-	-	-
Big Data SQL(有効化されている場合)	Big Data SQL(有効化されている場合)	Big Data SQL(有効化されている場合)	Big Data SQL(有効化されている場合)	Big Data SQL(有効化されている場合)
パッシブNavigator Key Trustee Server (HDFS透過的暗号化が有効化されている場合)	Hiveメタストア(もう一方のHiveメタストア・サービスが第1ラックにあります)	-	-	-

表2-5に、当初、シングルラック・クラスタとして構成され、その後拡張されたクラスタの最初のラックにおけるサービス・ロケーションを示します。

表2-5 最初のラックのサービス・ロケーション(シングルラック・クラスタが拡張された場合)

node01	node02	node03	Node04	Node05 - nn(2)
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	-	Navigator監視サーバーおよびNavigatorメタデータ・サーバー	-	-
JournalNode	-	JournalNode	-	-
NameNode	-	MySQL Primary	-	-
NodeManager (8ノード以下のクラスタ内)	NodeManager	NodeManager	NodeManager	NodeManager
-	-	ResourceManager	-	-
ZooKeeper	-	ZooKeeper	-	-
Kerberos KDC (MIT Kerberosが有効化され、BDA上のKDCが使用されている場合のみ)	Kerberos KDC (MIT Kerberosが有効化され、BDA上のKDCが使用されている場合のみ)	SparkHistoryServer	-	-
Sentry Server (Sentryが有効化されている場合のみ)	Sentry Server (Sentryが有効化されている場合のみ)	-	-	-
Big Data SQL(有効化されている場合)	Big Data SQL(有効化されている場合)	Big Data SQL(有効化されている場合)	Big Data SQL(有効化されている場合)	Big Data SQL(有効化されている場合)
アクティブNavigator Key Trustee Server (HDFS透過的暗号化が有効化されている場合)	-	-	-	-
Hive Metastore	-	-	-	-
Hueサーバー	-	-	Hueサーバー	-
Hueロード・バランサ	-	-	Hueロード・バランサ	-

^脚注 2 nnには追加ラック内のサーバーが含まれます。

表2-6に、当初、シングルラック・クラスタとして構成され、その後拡張されたクラスタの第2ラックにおけるサービス・ロケーションを示します。

表2-6 第2ラックのサービス・ロケーション(シングルラック・クラスタが拡張された場合)

node01	node02	node03	Node04	Node05 - nn
バランサ
Cloudera Manager Agent	Cloudera Manager Agent	Cloudera Manager Agent	Cloudera Manager Agent	Cloudera Manager Agent
DataNode	DataNode	DataNode	DataNode	DataNode
Failover Controller	-	-	-	-
JournalNode	Oozie、Solr	-	-	-
MySQL Backup	-	-	-	-
NameNode	-	-	-	-
NodeManager (8ノード以下のクラスタ内)	NodeManager	NodeManager	NodeManager	NodeManager
HttpFS	Oracle Data Integratorエージェント	-	-	-
-	ResourceManager	-	-	-
ZooKeeper	-	-	-	-
Big Data SQL(有効化されている場合)	Big Data SQL(有効化されている場合)	Big Data SQL(有効化されている場合)	Big Data SQL(有効化されている場合)	Big Data SQL(有効化されている場合)
パッシブNavigator Key Trustee Server (HDFS透過的暗号化が有効化されている場合)	Hive Metastore

注意:

1つのラックから2つのラックにクラスタを展開する場合、Mammothは最初のラックのノード2および4から重要なサービスをすべて、第2ラックのノード1および2に移動します。最初のラックのノード2および4は、非クリティカル・ノードになります。

2.6.4 MapReduceについて

Yet Another Resource Negotiator (YARN)は、バージョン3.0以降のOracle Big Data Applianceで実行されるMapReduceのバージョンです。MapReduce 1を使用して開発されたMapReduce (MRv1)アプリケーションをYARNで実行するには、再コンパイルが必要な場合があります。

ResourceManagerは、すべてのリソース管理タスクを実行します。MRAppMasterはジョブ管理タスクを実行します。各ジョブには独自のMRAppMasterがあります。NodeManagerには、マップ・タスク、リデュース・タスクまたはMRAppMasterを実行できるコンテナがあります。NodeManagerは使用可能なメモリーを使用してコンテナを動的に割り当てることができます。このアーキテクチャによりスケーラビリティが向上し、MRv1よりもクラスタを活用できます。

YARNはSparkおよびImpalaのリソースも管理します。

関連項目:

次のサイトで「Running Existing Applications on Hadoop 2 YARN」を参照してください。

http://hortonworks.com/blog/running-existing-applications-on-hadoop-2-yarn/

2.6.5 NameNodeの自動フェイルオーバー

NameNodeは、すべてのデータの場所を追跡するため、最も重要なプロセスです。正常に機能しているNameNodeがないと、クラスタ全体に障害が発生します。Apache Hadoop v0.20.2以前のバージョンは、ネームノードが1つしかないため、障害に対して脆弱です。

Cloudera's Distribution including Apache Hadoopのバージョン4 (CDH5)では、NameNodeの冗長性を維持することにより、この脆弱性が軽減されています。次に示すように、データは通常の運用時にレプリケートされます。

• CDHは、クラスタの最初の2つのノード上でNameNodeの冗長性を維持します。NameNodeの一方はアクティブ・モード、もう一方のNameNodeはホット・スタンバイ・モードです。アクティブNameNodeに障害が発生すると、そのアクティブNameNodeのロールは自動的にスタンバイNameNodeにフェイルオーバーされます。

• NameNodeのデータはミラー化されたパーティションに書き込まれるので、1つのディスクが失われても耐障害性が確保されます。このミラー化の処理は、オペレーティング・システムのインストールの一環として工場出荷時に行われます。

• アクティブNameNodeでは、ファイル・システム・メタデータへのすべての変更を2つ以上のJournalNodeプロセスに記録し、これをスタンバイNameNodeが読み取ります。3つのJournalNodeがあり、それらは各クラスタの最初の3つのノードで実行されます。

• ジャーナルに記録された変更は、チェックポインティングと呼ばれるプロセスで単一のfsimageファイルに定期的に統合されます。

Oracle Big Data Applianceで、NameNodeのデフォルト・ログ・レベルは、Oracle Audit Vault and Database FirewallプラグインをサポートするDEBUGです。このオプションが構成されていない場合、ログ・レベルをINFOにリセットできます。

注意:

Oracle Big Data Appliance 2.0以降のリリースでは、バックアップ用の外部NFSフィルタをサポートしておらず、NameNodeのフェデレーションを使用しません。

次の図は、NameNodeの自動フェイルオーバーをサポートしているプロセス間の関係を示しています。

図2-7 Oracle Big Data ApplianceでのNameNodeの自動フェイルオーバー

「図2-7 Oracle Big Data ApplianceでのNameNodeの自動フェイルオーバー」

2.6.6 ResourceManagerの自動フェイルオーバー

ResourceManagerは、クラスタ内のアプリケーション・タスクおよびアプリケーション・マスターにリソースを割り当てます。NameNodeと同様、ResourceManagerはクラスタの重要な障害ポイントです。すべてのResourceManagerで障害が起きると、すべてのジョブが実行を停止します。Oracle Big Data Appliance は、この脆弱性を軽減するためにCloudera 5でResourceManager High Availabilityをサポートしています。

CDHは、node03とnode04上の冗長なResourceManagerサービスを管理します。それらのサービスの1つがアクティブ・モードになり、その他のサービスはホット・スタンバイ・モードになります。アクティブ・サービスに障害が発生すると、そのアクティブResourceManagerのロールは自動的にスタンバイ・サービスにフェイルオーバーされます。フェイルオーバー・コントローラは不要です。

次の図は、ResourceManagerの自動フェイルオーバーをサポートしているプロセス間の関係を示しています。

図2-8 Oracle Big Data ApplianceでのResourceManagerの自動フェイルオーバー

「図2-8 Oracle Big Data ApplianceでのResourceManagerの自動フェイルオーバー」の説明

2.6.7 マップとリデュースのリソース割当て

Oracle Big Data ApplianceはメモリーをYARNに動的に割り当てます。割当ては、ノードの合計メモリー容量と、そのノードが4つのクリティカル・ノードのうちの1つであるかどうかによって変わります。

メモリーを追加した場合は、追加メモリーの80%に相当する容量を増やすようにNodeManagerコンテナ・メモリーを更新します。残りの20%はオーバーヘッド用に残します。

2.7 Oracle NoSQL Databaseクラスタについて

Oracle NoSQL Databaseクラスタにはクリティカル・ノードがなく、ストレージ・ノードは3倍にレプリケートされるため、クリティカルな障害のリスクが最小限に抑えられます。管理サービスは、レプリケーション・ファクタと同じ数のノードに分散されます。管理CLIと管理コンソールを使用して、管理プロセスをホストする任意のノードからクラスタを管理できます。

Mammothをホストするノード(クラスタの第1ノード)に障害が発生した場合、「障害が発生したノードを管理するための前提条件」の再インストールするための手順に従います

障害が発生しているOracle NoSQLノードを修理または交換するには、「障害が発生している非クリティカル・ノードの管理」の手順に従います。

2.8 Kafkaクラスタについて

Kafkaクラスタの重要なサービスは次のとおりです。

• ノード1: Puppetマスター、Zookeper、Kafkaブローカ。

• ノード2: MySQLバックアップ・データベース、Zookeper、Kafkaブローカ。

• ノード3: Zookeeper、Mysqlプライマリ・データベース、Cloudera Managerサーバー、Kafkaブローカ。

2.8.1 Kafkaクラスタ上でサービスが実行される場所

CDHクラスタと同様に、マルチラックKafkaクラスタでのサービスの分散方法は、そのクラスタがマルチラックとして開始されたものか、シングルラック・クラスタから拡張されたものかによってわずかに異なります。

Oracle Big Data Applianceは、開発目的で3ノード・クラスタを使用できます。

注意:

通常、3ノードKafkaクラスタは本番環境には適していません。本番環境のKakaクラスタにお薦めされる最小のクラスタ・サイズは4ノードです。これによりに障害発生時のリカバリが可能になります。

表2-7 シングル・ラックKafkaクラスタでのサービス・ロケーション

Node1	Node2	Node3	すべての追加ノード
Kafka Broker	Kafka Broker	Kafka Broker	Kafka Broker
Zookeeper	Zookeeper	Zookeeper	Cloudera Manager Agent
KerberosマスターKDC (Kerberos MITが有効化されている場合)	KerberosスレーブKDC (Kerberos MITが有効化されている場合)	Cloudera Manager (およびCMロール)	—
—	MySQL Backup	MySQL Primary	—

表2-8 マルチラックKafkaクラスタの最初のラックでのサービス・ロケーション(シングルラック・クラスタから拡張した場合)

Node1	Node2	Node3	すべての追加ノード
Kafka Broker	Kafka Broker	Kafka Broker	Kafka Broker
Cloudera Manager Agent	Cloudera Manager Agent	Cloudera Manager Agent	Cloudera Manager Agent
Zookeeper	—	Zookeeper	—
—	—	MySQL Primary	—

表2-9 マルチラックKafkaクラスタの追加ラックでのサービス・ロケーション(シングルラック・クラスタから拡張した場合)

Node1	Node2	Node3	すべての追加ノード
Kafka Broker	Kafka Broker	Kafka Broker	Kafka Broker
Cloudera Manager Agent	Cloudera Manager Agent	Cloudera Manager Agent	Cloudera Manager Agent
Zookeeper	—	—	—
MySQLのバックアップ(2番目のラックのみ)	—	—	—

表2-10 マルチラックKafkaクラスタの最初のラックでのサービス・ロケーション(マルチラックとして開始した場合)

Node1	Node2	Node3	すべての追加ノード
Kafka Broker	Kafka Broker	Kafka Broker	Kafka Broker
Cloudera Manager Agent	Cloudera Manager Agent	Cloudera Manager Agent	Cloudera Manager Agent
Zookeeper	Zookeeper	—	—
—	MySQL Primary	—	—

表2-11 マルチラックKafkaクラスタの追加ラックでのサービス・ロケーション(マルチラックとして開始した場合)

Node1	Node2	Node3	すべての追加ノード
Kafka Broker	Kafka Broker	Kafka Broker	Kafka Broker
Cloudera Manager Agent	Cloudera Manager Agent	Cloudera Manager Agent	Cloudera Manager Agent
Zookeeper	—	—	—
MySQLのバックアップ(2番目のラックのみ)	—	—	—

2.9 ソフトウェアの可用性に与えるハードウェアの影響

サーバー障害の影響は、CDHクラスタ内におけるサーバーの機能によって異なります。Oracle Big Data Applianceサーバーは、コモディティ・ハードウェアよりも堅牢なため、ハードウェア障害が発生することはほとんどありません。この項では、プライマリ・ラックの様々なサーバー上で実行される重要性の高いサービスに焦点を当てています。詳細なリストは、「シングルラックCDHクラスタ上でサービスが実行される場所」を参照してください。

注意:

マルチラック・クラスタでは、一部の重要なサービスが第2ラックの第1サーバーで実行されます。「マルチラックCDHクラスタ上でサービスが実行される場所」を参照してください。

2.9.1 論理ディスク・レイアウト

各サーバーには12基のディスクが搭載されています。次の表でディスク・パーティショニングについて説明します。

オペレーティング・システムはディスク1および2にインストールされます。これら2つのディスクはミラー化されます。これらには、Linuxオペレーティング・システム、インストールされたすべてのソフトウェア、NameNodeデータおよびMySQL Databaseのデータが含まれます。NameNodeおよびMySQLデータベースのデータは、2つのサーバー間でレプリケートされているため、合計で4つのコピーがあります。表に示すように、ディスク1および2が4 TBのドライブの場合、これらには3440 GBのHDFSデータ・パーティションが含まれます。ディスク1および2が8 TBの場合、それぞれに7314 GBのHDFSデータ・パーティションが含まれます。

ドライブ3から12にはそれぞれ、1つのHDFSまたはOracle NoSQL Databaseデータ・パーティションが含まれます

表2-12 Oracle Big Data Applianceサーバーのディスク・パーティショニング

ディスク1および2 (OS)	ディスク3 – 12 (データ)
8 TBドライブ: Number Start End Size File system Name Flags 1 1049kB 500MB 499MB ext4 primary boot 2 500MB 501GB 500GB primary raid 3 501GB 550GB 50.0GB linux-swap(v1) primary 4 550GB 7864GB 7314GB ext4 primary	8 TBドライブ: Number Start End Size File system Name Flags 1 1049kB 7864GB 7864GB ext4 primary
4 TBドライブ: Number Start End Size File system Name Flags 1 1049kB 500MB 499MB ext4 primary boot 2 500MB 501GB 500GB primary raid 3 501GB 560GB 59.5GB linux-swap(v1) primary 4 560GB 4000GB 3440GB ext4 primary	4 TBドライブ: Number Start End Size File system Name Flags 1 1049kB 4000GB 4000GB ext4 primary

2.9.2 クリティカルおよび非クリティカルCDHノード

クリティカル・ノードは、クラスタが正常に動作し、すべてのサービスをユーザーに提供するために必要です。これとは対照的に、非クリティカル・ノードに障害が発生しても、クラスタはサービスを失うことなく動作し続けます。

シングルラック・クラスタでは、重要なサービスはクラスタの最初の4つのノードに初期インストールされます。残りのノード(node05から最大でnode18まで)は重要性の低いサービスのみを実行します。クリティカル・ノードのいずれかでハードウェア障害が発生した場合は、別の非クリティカル・サーバーにサービスを移行できます。たとえば、node02に障害が発生した場合、重要なサービスをnode05に移行できます。表2-2は、シングル・ラック上に構成されたクラスタのサービスの初期ロケーションを示したものです。

マルチラック・クラスタでは、一部の重要なサービスが第2ラックの第1サーバーで実行されます。「シングルラックCDHクラスタ上でサービスが実行される場所」を参照してください。

2.9.2.1 高可用性または単一障害点

一部のサービスには高可用性と自動フェイルオーバーが含まれています。単一障害点を含むサービスもあります。次のリストに、重要なサービスを示します。

• NameNodes: 高可用性と自動フェイルオーバー

• ResourceManagers: 高可用性と自動フェイルオーバー

• MySQL Database: プライマリ・データベースおよびバックアップ・データベースは、バックアップ・データベースに対するプライマリ・データベースのレプリケーションで構成されます。自動フェイルオーバーはありません。プライマリ・データベースに障害が発生すると、クラスタの機能は失われますが、データは失われません。

• Cloudera Manager: Cloudera Managerサーバーは1つのノードで実行されます。障害が発生すると、Cloudera Manager機能は使用できません。

• Hueサーバー、Hueロード・バランサ、Sentry、Hiveメタストア: 高可用性

• Oozieサーバー、Oracle Data Integratorエージェント: これらのサービスには冗長性はありません。ノードに障害が発生すると、サービスは使用できません。

2.9.2.2 重要なサービスが実行される場所

次の表に、重要なサービスがCDHクラスタで実行される場所を示します。これらの4つのノードの詳細は、この後のトピックで説明します。

表2-13 シングル・ラックでの重要なサービスの場所

ノード名	重要な機能
第1NameNode	バランサ、フェイルオーバー・コントローラ、JournalNode、NameNode、Puppet Master、ZooKeeper
第2NameNode	フェイルオーバー・コントローラ、JournalNode、MySQLバックアップ・データベース、NameNode、ZooKeeper
第1ResourceManagerノード	Cloudera Manager Server、JobHistory、JournalNode、MySQLプライマリ・データベース、ResourceManager、ZooKeeper
第2ResourceManagerノード	Hive、Hue、Oozie、Solr、Oracle Data Integrator Agent、ResourceManager

最初に、シングルラック・クラスタでは、最初の4つのノード上に4つの重要なノードが作成されます。「シングルラックCDHクラスタ上でサービスが実行される場所」を参照してください

マルチラック・クラスタでは、第2NameNodeノードと第2ResourceManagerノードは第2ラックの最初の2つのノードに移動されます。「マルチラックCDHクラスタ上でサービスが実行される場所」を参照してください。

2.9.3 第1NameNodeノード

第1NameNodeに障害が発生するか、オフライン(再起動など)になると、第2NameNodeが自動的に引き継いで、クラスタの正常なアクティビティを維持します。

または、第2NameNodeがすでにアクティブな場合は、バックアップなしで動作し続けます。NameNodeが1つのみの場合、クラスタは障害に対して脆弱です。クラスタが、自動フェイルオーバーに必要な冗長性を失うためです。

Puppetマスターもこのノードで実行されます。MammothユーティリティではPuppetを使用するので、たとえばラック内の別の場所にあるディスク・ドライブを交換する必要がある場合、ソフトウェアのインストールまたは再インストールはできません。

2.9.4 第2NameNodeノード

第2NameNodeに障害が発生すると、NameNodeの機能は第1NameNode (node01)にフェイルオーバーされるか、そのままバックアップなしで動作し続けます。ただし、第1NameNodeにも障害が発生すると、クラスタは自動フェイルオーバーに必要な冗長性を失っています。

MySQLバックアップ・データベースもこのノードで実行されます。MySQL Databaseは動作を継続しますが、マスター・データベースのバックアップはありません。

2.9.5 第1ResourceManagerノード

第1ResourceManagerに障害が発生するか、(ノードが実行されているサーバーの再起動などによって)オフラインになると、第2ResourceManagerが自動的に機能を引き継ぎ、MapReduceタスクをクラスタの特定のノードへと分配します。

第2ResourceManagerがすでにアクティブな場合は、第1ResourceManagerがアクセス不可になると、バックアップなしでResourceManagerとして動作し続けます。1つのResourceManagerのみを使用する場合、クラスタは自動フェイルオーバーに必要な冗長性を失うため、脆弱になります。

第1ResourceManagerに障害が発生するか、(再起動などによって)オフラインになると、第2ResourceManagerが自動的に機能を引き継ぎ、MapReduceタスクをクラスタの特定のノードへと分配します。

または、第2ResourceManagerがすでにアクティブな場合は、バックアップなしで動作し続けます。ResourceManagerが1つのみの場合、クラスタは障害に対して脆弱です。クラスタが、自動フェイルオーバーに必要な冗長性を失うためです。

次のサービスも影響を受けます。

• Cloudera Manager: このツールは、CDHクラスタ全体の一元管理機能を提供します。このツールがない場合は、「Hadoop監視ユーティリティの使用方法」で説明したユーティリティを使用すれば、引き続きアクティビティを監視できます。

• MySQL Database: Cloudera Manager、Oracle Data Integrator、HiveおよびOozieはMySQLデータベースを使用しています。データは自動的にレプリケートされますが、マスター・データベース・サーバーが停止していると、それにはアクセスできません。

2.9.6 第2ResourceManagerノード

第2ResourceManagerノードに障害が発生すると、ResourceManagerの機能は第1ResourceManagerにフェイルオーバーされるか、そのままバックアップなしで動作し続けます。ただし、第1ResourceManagerにも障害が発生すると、クラスタは自動フェイルオーバーに必要な冗長性を失っています。

次のサービスも影響を受けます。

• Oracle Data Integratorエージェント このサービスは、Oracle Big Data Connectorsの1つであるOracle Data Integratorをサポートします。Oracle Data Integratorは、ResourceManagerノードがダウンしているときには使用できません。

• Hive: Hiveは、HDFSに格納されているデータへのSQLライクなインタフェースを備えています。Oracle Big Data SQLおよびOracle Big Data Connectorsの大部分はHive表にアクセスできますが、このノードに障害が発生した場合、この表は使用できません。

• Hue: この管理ツールは、ResourceManagerがダウンしているときには使用できません。

• Oozie: このワークフローおよび調整サービスはResourceManagerノードで実行され、このノードがダウンしているときには使用できません。

2.9.7 非クリティカルCDHノード

非クリティカル・ノードはオプションのため、障害が発生しても、Oracle Big Data Applianceはサービスを失うことなく動作し続けます。NameNodeでは失われたデータを自動的にレプリケートして、常に3つのコピーを保持します。MapReduceジョブは、クラスタの別の場所に保存されているデータのコピーに対して実行されます。ワークロードの分散先のサーバーが少なくなるので、処理能力のみが失われることになります。

2.10 ハードウェア障害の管理

サーバーに障害が発生した場合、できるかぎり短い中断時間で、クラスタのサービスを保守するステップを実行する必要があります。次の手順で説明するように、bdacliユーティリティを使用して、障害が発生しているサーバーを簡単に管理できます。管理ステップの1つはデコミッショニングと呼ばれます。デコミッショニングは、すべてのサービスのすべてのロールを停止するため、データが失われることはありません。Cloudera Managerでは、CDHノードを終了する前にデコミッションする必要があります。

非クリティカル・ノードに障害が発生しても、サービスが失われることはありません。ただし、CDHクラスタでクリティカル・ノードに障害が発生した場合、「ソフトウェアの可用性に与えるハードウェアの影響」で説明するように、単一障害点を持つサービスは使用できません。次の選択肢のどちらかに決める必要があります。

• 修理が行われるのを待機し、修理が完了するまでサービスが失われた状態が続きます。

• 重要なサービスを別のノードに移動します。これを選択すると、一部のクライアントを新しいノードのアドレスで再構成する必要がある場合があります。たとえば、第2ResourceManagerノード(通常はnode03)で障害が発生した場合、ユーザーはブラウザを新しいノードにリダイレクトしてCloudera Managerにアクセスする必要があります。

サービスの喪失とクライアントを再構成する不便さとを比較検討する必要があります。

2.10.1 障害が発生しているノードを管理するための前提条件

CDHノードまたはOracle NoSQL Databaseノードとして構成されているかどうか、障害が発生しているサーバーまたは障害が発生したサーバーを管理する前に次の操作を実行してください。

• サービスまたはサーバーを再起動してみます。

• 障害が発生しているノードがクリティカルか非クリティカルかを判断します。

• 障害が発生しているノードが、Mammothがインストールされているノードの場合:

  1. CDHノードの場合、障害が発生しているノードと同じクラスタの非クリティカル・ノードを選択します。

     NoSQLノードの場合、最初に障害が発生したサーバーを修理または交換し、次のステップに使用します。

  2. Mammothバンドルを該当するノードにアップロードして解凍します。

  3. 次のようなコマンドを使用して、BDAMammoth-version.runからすべてのファイルを抽出します。

     # ./BDAMammoth-ol6-4.0.0.run

     後で、このノードからすべてのMammoth操作を実行する必要があります。

     Mammothユーティリティの詳細は、『Oracle Big Data Applianceオーナーズ・ガイド』を参照してください。

  4. 障害が発生しているノードを管理するためのこの項の適切な手順に従います。

  サービスが以前に移行されていないかぎり、Mammothはクラスタの第1ノードにインストールされます。

2.10.2 障害が発生しているCDHクリティカル・ノードの管理

CDHクラスタのみクリティカル・ノードがあります。

障害が発生しているクリティカル・ノードを管理するには、次の手順を実行します。

1. Mammothがインストールされているノードにrootとしてログインします。

2. サービスを非クリティカル・ノードに移行します。node_nameを、障害が発生しているノードの名前(bda1node02など)に置換します。

   bdacli admin_cluster migrate node_name

   コマンドが完了すると、node_nameがデコミッションされ、以前の非クリティカル・ノードでサービスが実行されます。

3. ユーザーが必要に応じてクライアントを新しいクリティカル・ノードにリダイレクトできるように、変更をユーザー・コミュニティに通知します。

4. 障害が発生したサーバーを修理または交換します。

5. rootとしてMammothノードから、修理または交換したサーバーを非クリティカル・ノードとして再プロビジョニングします。node_nameには、移行されたノードと同じ名前(bda1node02など)を使用します。

   bdacli admin_cluster reprovision node_name

6. 障害が発生したノードがHBaseやImpalaのようなサービス(Mammothによってインストールされているが、構成されていない状態)をサポートしていた場合、Cloudera Managerを使用してそれらを新しいノードで再構成します。

2.10.3 障害が発生している非クリティカル・ノードの管理

次の手順を使用して、CDHまたはNoSQLクラスタの障害が発生しているノードを交換します。

障害が発生している非クリティカル・ノードを管理するには、次の手順を実行します。

1. Mammothがインストールされているノード(通常はnode01)にrootとしてログインします。

2. 障害が発生しているノードをデコミッションします。node_nameを、障害が発生しているノードの名前に置換します。

   bdacli admin_cluster decommission node_name

3. 障害が発生したサーバーを修理または交換します。

4. Mammothノードでrootとして、修理または交換したサーバーを再コミッションします。node_nameには、デコミッションされたノードと同じ名前を使用します。

   bdacli admin_cluster recommission node_name

5. CDHクラスタの場合、Cloudera Managerにログインし、再コミッションされたノードを探します。HDFS DataNode、YARN NodeManager、および実行中である必要がある他の任意のロールに緑色のステータス・ランプが表示されていることを確認します。されていない場合は、それらを手動で再起動します。

関連項目:

bdacliの構文の詳細は、『Oracle Big Data Applianceオーナーズ・ガイド』を参照してください。

2.11 Oracle Big Data Applianceの停止および起動

この項では、Oracle Big Data Applianceを正常に停止して再起動する方法について説明します。

• 前提条件

• Oracle Big Data Applianceの停止

• Oracle Big Data Applianceの起動

2.11.1 前提条件

rootアクセス権が必要です。dcliユーティリティを使用できるように、クラスタにパスワードなしSSHが設定されている必要があります。

パスワードなしSSHが設定されていることを確認するには、次の手順を実行します。

1. クラスタの第1ノードにrootとしてログインします。

2. dcliコマンドを使用して、コマンドが動作していることを確認します。このコマンドは、クラスタ内のすべてのノードのIPアドレスおよびホスト名を返します。

   # dcli -C hostname
   192.0.2.1: bda1node01.example.com
   192.0.2.2: bda1node02.example.com
        .
        .
        .

3. これらの結果が得られない場合は、クラスタでdcliを設定します。

   # setup-root-ssh -C

関連項目:

これらのコマンドの詳細は、『Oracle Big Data Applianceオーナーズ・ガイド』を参照してください。

2.11.2 Oracle Big Data Applianceの停止

次の手順に従って、すべてのOracle Big Data Applianceソフトウェアおよびハードウェア・コンポーネントを停止します。

注意:

システムが停止すると、次のサービスは自動的に停止します。処理を実行する必要はありません。

• Oracle Enterprise Managerエージェント

• 自動サービス・リクエスト・エージェント

2.11.2.1 すべての管理対象サービスの停止

Cloudera Managerを使用して、Cloudera Managerが管理するサービス(flume、hbase、hdfs、hive、hue、mapreduce、oozieおよびzookeeper)を停止します。

1. adminユーザーとしてCloudera Managerにログインします。

   「Cloudera Managerを使用した操作の管理」を参照してください。

2. 開始ページの「Status」ペインで、クラスタのメニューを展開し、「Stop」をクリックした後、確認するように要求されたら「Stop」を再びクリックします。図2-9を参照してください。

   このページに移動するには、「Home」タブをクリックし、「Status」サブタブをクリックします。

3. 「Command Details」ページで、すべてのプロセスが停止したら「Close」をクリックします。
4. Cloudera Management Servicesの同じペインで、mgmtサービスのメニューを展開し、「Stop」をクリックします。
5. Cloudera Managerからログアウトします。

図2-9 HDFSサービスの停止

「図2-9 HDFSサービスの停止」の説明

2.11.2.2 Cloudera Manager Serverの停止

次の手順に従って、Cloudera Manager Serverを停止します。

1. Cloudera Managerが実行されているノード(最初はnode03)にrootとしてログインします。

   注意:

   残りのタスクでは、サーバーにrootとしてログインしているとみなされます。dcliコマンドを使用すると、任意のサーバーからコマンドを入力できます。この例では、クラスタ内の任意のノードからnode03でpwdコマンドを実行します。

   # dcli -c node03 pwd

2. Cloudera Managerサーバーを停止します。

   # service cloudera-scm-server stop
   Stopping cloudera-scm-server:                              [  OK  ]

3. サーバーが停止したことを確認します。

   # service cloudera-scm-server status
   cloudera-scm-server is stopped

Cloudera Managerを停止した後、Webコンソールを使用してアクセスすることはできません。

2.11.2.3 Oracle Data Integratorエージェントの停止

Oracle Data Integratorがクラスタで使用されている場合:

1. Oracle Data Integratorエージェントのステータスを確認します。

   # dcli -C service odi-agent status

2. Oracle Data Integratorエージェントが実行中の場合は、停止します。

   # dcli -C service odi-agent stop

3. Oracle Data Integratorエージェントの実行が停止したことを確認します。

   # dcli -C service odi-agent status

2.11.2.4 NFSディレクトリのディスマウント

すべてのノードがnode03でNFSディレクトリを共有しており、追加のディレクトリが存在する場合もあります。NFSディレクトリ(/opt/exportdir)を含むサーバーを使用できない場合、停止しようとすると他のサーバーがハングします。したがって、まずNFSディレクトリをディスマウントする必要があります。

1. マウントされている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)上の共有ディレクトリを示します。

2. 共有ディレクトリをディスマウントします。

   # dcli -C umount /opt/shareddir

3. カスタムNFSディレクトリをディスマウントします。

2.11.2.5 サーバーの停止

Linuxのshutdown -hコマンドは、個別のサーバーの電源を切断します。dcli -gコマンドを使用すると、複数のサーバーを停止できます。

1. クラスタ内の他のサーバー(つまり、ログインしているサーバーを除く)の名前またはIPアドレスをリストしたファイルを作成します。
2. 他のサーバーを停止します。

   # dcli -g filename shutdown -h now

   filenameには、ステップ1で作成したファイルの名前を入力します。

3. ログインしているサーバーを停止します。

   # shutdown -h now

2.11.2.6 インフィニバンドおよびCiscoスイッチの停止

ネットワーク・スイッチを停止するには、データ・センターのPDUまたはブレーカをオフにします。スイッチがオフになるのは、電源を切断した場合のみです。

ネットワーク・スイッチには電源ボタンがありません。停止するのは、電源を切断した場合のみです。

スイッチを停止するには、2つのPDUのすべてのブレーカをオフにします。

2.11.3 Oracle Big Data Applianceの起動

次の手順に従って、ハードウェアの電源を投入し、Oracle Big Data Appliance上のすべてのサービスを開始します。

2.11.3.1 Oracle Big Data Applianceの電源投入

1. 両方のPDUの12個すべてのブレーカのスイッチを入れます。
2. Oracle ILOMおよびLinuxオペレーティング・システムがサーバーで起動するには4から5分かかります。

サーバーが自動的に起動しない場合は、サーバーの前面にある電源ボタンを押してローカルで起動するか、または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

2.11.3.2 HDFSソフトウェア・サービスの開始

Cloudera Managerが制御するすべてのHDFSサービスを開始するには、Cloudera Managerを使用します。

1. Cloudera Managerが実行されているノード(最初はnode03)にrootとしてログインします。

   注意:

   残りのタスクでは、サーバーにrootとしてログインしているとみなされます。dcliコマンドを使用すると、任意のサーバーからコマンドを入力できます。この例では、クラスタ内の任意のノードからnode03でpwdコマンドを実行します。

   # dcli -c node03 pwd

2. Cloudera Managerがnode03で自動的に起動したことを確認します。

   # service cloudera-scm-server status 
   cloudera-scm-server (pid  11399) is running...

3. 実行されていない場合は、起動します。

   # service cloudera-scm-server start

4. adminユーザーとしてCloudera Managerにログインします。

   「Cloudera Managerを使用した操作の管理」を参照してください。

5. 開始ページの「Status」ペインで、クラスタのメニューを展開し、「Start」をクリックした後、確認するように要求されたら「Start」を再びクリックします。図2-9を参照してください。

   このページに移動するには、「Home」タブをクリックし、「Status」サブタブをクリックします。

6. 「Command Details」ページで、すべてのプロセスが開始されたら「Close」をクリックします。
7. Cloudera Management Servicesの同じペインで、mgmtサービスのメニューを展開し、「Start」をクリックします。
8. Cloudera Managerからログアウトします(オプション)。

2.11.3.3 Oracle Data Integratorエージェントの起動

Oracle Data Integratorがこのクラスタで使用されている場合:

1. エージェントのステータスを確認します。

   # /opt/oracle/odiagent/agent_standalone/oracledi/agent/bin/startcmd.sh OdiPingAgent [-AGENT_NAME=agent_name]

2. エージェントを起動します。

   # /opt/oracle/odiagent/agent_standalone/oracledi/agent/bin/agent.sh [-NAME=agent_name] [-PORT=port_number]

2.12 Oracle Big Data SQLの管理

Oracle Big Data SQLは、アドオン・サービスとしてCloudera Managerに登録されます。Cloudera Managerを使用すると、CDHサービスと同じ方法でOracle Big Data SQLサービスまたは個別のロール・インスタンスを起動、停止および再起動できます。

Cloudera ManagerはOracle Big Data SQLサービスの状態を監視し、サービスの停止をレポートして、サービスが正常に機能していない場合はアラートを送信します。

2.12.1 Oracle Big Data SQLサービスの追加および削除

Oracle Big Data SQLは、Oracle Big Data Applianceにインストールできるオプションのパッケージです。Cloudera Managerを使用して、Oracle Big Data SQLがインストールされているかどうかを判別することはできますが、Oracle Big Data Appliance上のCDHクラスタにサービスを追加または削除するために使用することはできません。

このソフトウェアの1つのバージョンが、Oracle Big Data Applianceの各リリースのMammothバンドルに含まれています。バンドルされたバージョンは、ソフトウェアの初期インストール時またはアップグレード時に他のクライアント・ソフトウェアとともにインストールすることもできます。Oracle Big Data Applianceに含まれているものよりも新しいバージョンのOracle Big Data SQLを利用できることがあります。Oracle Big Data Applianceオーナーズ・ガイドのはじめにには、各リリースでの変更点が記載されています(リリースにバンドルされているOracle Big Data SQLのバージョンを含む)。使用している現在のリリースのOracle Big Data Applianceと互換性がある他のバージョンのOracle Big Data SQLについての最新情報は、My Oracle Supportの『Oracle Big Data SQL Master Compatibility Matrix』(Doc ID 2119369.1)を参照してください。

Oracle Big Data Applianceに含まれているOracle Big Data SQLのバージョンをインストールするには、Mammothがインストールされているサーバー(通常はクラスタの最初のノード)にログインし、bdacliユーティリティで次のコマンドを使用します。

• Oracle Big Data SQLを有効化するには、次の手順を実行します。

  bdacli enable big_data_sql

• Oracle Big Data SQLを無効化するには、次の手順を実行します。

  bdacli disable big_data_sql

他のバージョンのOracle Big Data SQLを追加または削除するには、そのリリースのインストール・ガイドを参照してください。

Oracle Big Data SQLには別個のライセンスが必要となります。このライセンスはOracle Big Data Applianceのライセンス契約には含まれていません。

2.12.2 Oracle Big Data SQL用のイーサネット接続とインフィニバンド接続からの選択

Oracle Big Data SQL用に、クライアント・イーサネット・ネットワークとインフィニバンド・ネットワークのいずれかを使用してOracle Big Data ApplianceとOracle Databaseを接続できます。

注意:

現在のところ、Oracle SPARC SuperClusterとOracle Big Data Applianceの間のOracle Big Data SQL用イーサネット・ネットワーキングはサポートされていません。

Oracle Big Data SQL用にイーサネット・ネットワーキングとインフィニバンド・ネットワーキングのいずれかを指定できるのは、次の3つの時点です。

• Oracle Big Data Appliance構成ユーティリティを使用してMammothインストールの準備を行うとき。

• Mammothを実行した後、Oracle Big Data SQLインストールのOracle Database側のデプロイメントを行う前。

• Oracle Big Data SQLが完全にデプロイされた後。

適切なネットワークの決定は、最も早い段階、つまり構成ユーティリティを使用するときに行うのが一番です。

Oracle Big Data Appliance構成ユーティリティでインフィニバンドまたはイーサネットを選択

Oracle Big Data Appliance構成ユーティリティには、デフォルトのインフィニバンド接続とイーサネット経由の接続から選択できるオプションが用意されています。構成ユーティリティの「Cluster」ページに次の質問があります。

Is Big Data SQL using InfiniBand?

この質問に答えないと、デフォルトでインフィニバンド・ネットワークが使用されます。Yesと答えた場合にもインフィニバンドが使用されます。イーサネット接続を選択するには、Noと答えます。

Oracle Big Data SQLをOracle Database Serverにデプロイする前にイーサネットに切替え

Mammothインストールを実行した後、Oracle Big Data SQLのデータベース側インストール・バンドルを作成してデプロイする前に、次のステップに従ってイーサネット接続またはインフィニバンド接続にリセットできます。

1. MammothインストールにOracle Big Data SQLを含めることを選択した場合は、rootとして、Mammothの終了後にOracle Big Data SQLを無効にします。

   # bdacli disable big_data_sql

2. 構成マネージャを実行しているノードで、ファイル/opt/oracle/bda/install/state/config.jsonのバックアップを作成し、rootとして元のファイルを編集のために開きます。

3. パラメータBDS_IB_CONNECTIONを見つけます。このパラメータに指定できる値は次のとおりです。

   • FALSE – イーサネットベースのクライアント・ネットワークのIPアドレスおよびマスクを使用する場合。

   • TRUE – インフィニバンド・ネットワークのIPアドレスおよびマスクを使用する場合。

   • デフォルトでは、値を指定しないとインフィニバンド・ネットワークが使用されます。

   Oracle Big Data SQL用にイーサネット接続を選択するには、BDS_IB_CONNECTIONをFALSEに設定し、ファイルを保存します。

4. Oracle Big Data SQLを再度有効にします。

   # bdacli enable big_data_sql

5. 『Oracle Big Data SQLインストレーション・ガイド』の説明に従って、データベース側インストール・バンドルを生成してデプロイします。バンドルに含まれるインストーラにより、データベース側でインフィニバンド接続が構成されます(それが前のステップで選択したネットワークである場合)。インストレーション・ガイドに記載されているように、バンドルは各データベース・ノードにデプロイする必要があります。

Oracle Big Data SQLがOracle Database Serverにデプロイされた後でインフィニバンドとイーサネットを切替え

Oracle Big Data SQLが完全にデプロイされた後でネットワークを切り替える場合、Oracle Database側のすべてのノードでインストールの再構成が必要になります。データベース側インストール・バンドルを再作成し、再デプロイする必要があります。

1. 上で述べた最初の4つのステップの説明に従い、Oracle Big Data SQLを無効にして、構成マネージャを実行するノードでconfig.jsonを編集します。目的のネットワークを使用するようにBDS_IB_CONNECTIONを設定した後、Oracle Big Data SQLを再度有効にします。

2. この場合、データベース・バンドルを生成してデプロイする前に、Oracle Big Data SQLによってインストールされたBDSSetupディレクトリにCDして、次のコマンドを実行します。これにより、再構成されたデータベース側インストール・バンドルが作成されます。

   [root@myclustermgmtserver: BDSSetup] # ./setup-bds reconfigure bds-config.json
   [root@myclustermgmtserver: BDSSetup] # ./cd db
   [root@myclustermgmtserver: db] # ./bds-database-create-bundle.sh --reconfigure

3. この新しいバンドルをすべてのデータベース・ノードにデプロイし、インストールします。

関連項目:

『Oracle Big Data SQLインストレーション・ガイド』に、Oracle Big Data SQLのインストールと構成に関する詳細な情報が記載されています。

2.12.3 Oracle Big Data SQLへのリソースの割当て

Linuxカーネルのコントロール・グループ(Cgroup)のプロパティ値を変更すると、Oracle Big Data SQL用にリソースを予約できます。

リソース管理の構成設定を変更するには、次の手順を実行します。

1. adminとしてCloudera Managerにログインします。

2. 「Home」ページで、サービスのリストからbigdatasqlをクリックします。

3. bigdatasqlページで、「Configuration」をクリックします。

4. 「Category」で、「BDS Server Default Group」を展開し、「Resource Management」をクリックします。

5. 必要に応じて、次のプロパティの値を変更します。

   • Cgroup CPU Shares

   • Cgroup I/O Weight

   • Cgroup Memory Soft Limit

   • Cgroup Memory Hard Limit

   ガイドラインのページの「Description」列を確認します。

6. 「Save Changes」をクリックします。

7. 「Actions」メニューから、「Restart」をクリックします。

次の図に、bigdatasqlサービスの構成ページを示します。

図2-10 Oracle Big Data SQLのCgroup設定の変更

「図2-10 Oracle Big Data SQLのCgroup設定の変更」の説明

関連項目:

「サービス間でのリソースの割当て」。

2.13 Oracle Big Data Applianceのセキュリティ

Oracle Big Data Applianceではソフトウェアやデータの不正利用を防ぐための予防策を取ることができます。

この項の内容は次のとおりです。

• 事前定義済のユーザーおよびグループについて

• ユーザー認証について

• ファイングレイン認証について

• Oracle Big Data Applianceで使用されるポート番号

• Puppetのセキュリティについて

2.13.1 事前定義済のユーザーおよびグループについて

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です。

注意:

インストール時に作成されたユーザーは、ソフトウェアの操作に必要なため、削除、再作成および変更はしないでください。

次の表に、Oracle Big Data Applianceソフトウェアのインストール時に自動的に作成され、CDHコンポーネントおよびその他のソフトウェア・パッケージによって使用されるオペレーティング・システム・ユーザーおよびグループを示します。

表2-14 オペレーティング・システム・ユーザーおよびグループ

ユーザー名	グループ	使用者	ログイン権限
flume	flume	Apache Flume親およびノード	なし
hbase	hbase	Apache HBaseプロセス	なし
hdfs	hadoop	NameNode、DataNode	なし
hive	hive	Hiveメタストアおよびサーバー・プロセス	なし
hue	hue	Hueプロセス	なし
mapred	hadoop	ResourceManager、NodeManager、Hive Thriftデーモン	あり
mysql	mysql	MySQLサーバー	あり
oozie	oozie	Oozieサーバー	なし
oracle	dba、oinstall	Oracle NoSQL Database、Oracle Loader for Hadoop、Oracle Data IntegratorおよびOracle DBA	あり
puppet	puppet	Puppet親(rootとして実行されるpuppetノード)	なし
sqoop	sqoop	Apache Sqoopメタストア	なし
svctag		自動サービス・リクエスト	なし
zookeeper	zookeeper	ZooKeeperプロセス	なし

2.13.2 ユーザー認証について

Oracle Big Data Applianceは、ソフトウェア・インストールのオプションとしてKerberosセキュリティをサポートしています。Kerberosで保護されているクラスタにアクセスするためのクライアントとユーザーの設定の詳細は、「Oracle Big Data Applianceへのユーザー・アクセスのサポート」を参照してください。

2.13.3 ファイングレイン認証について

Hadoop上の通常の認可モデルはHDFSファイル・レベルであり、ユーザーはファイル内のすべてのデータへのアクセス権を持っているか、またはまったく持っていないかのどちらかです。対照的に、Apache SentryはHiveおよびImpala SQL問合せエンジンと統合され、Hadoopに格納されているデータに対するファイングレイン認証の機能を備えています。

Mammothユーティリティ・バージョン2.5より、Oracle Big Data Applianceは、ソフトウェアのインストール中にSentryを自動的に構成します。

関連項目:

• Cloudera Managerのヘルプ

• My Oracle Supportのbdacliを使用してOracle Big Data Appliance v4.2以上にSentryを追加または削除する方法(Doc ID 2052733.1)。

2.13.4 HDFSでの透過的暗号化について

HDFSでの透過的暗号化では、ディスク上に保存されているHadoopデータを保護します。HDFSでの透過的暗号化をOracle Big Data Appliance上のクラスタについて有効化すると、ディスク上の暗号化されたゾーン(HDFSディレクトリ)に対するデータ書込みとデータ読取りが、自動的に暗号および復号化されます。このプロセスは、そのデータを処理しているアプリケーションには表示されないため、透過的です。

HDFSでの透過的暗号化は、パフォーマンスに若干影響する可能性はありますが、Hadoopデータへのユーザー・アクセスには影響しません。

HDFSでの透過的暗号化は、Mammothユーティリティによるソフトウェアの初期インストール時に選択できるオプションです。また、bdacliユーティリティを使用して、いつでもHDFSでの透過的暗号化を有効または無効にすることもできます。HDFSでの透過的暗号化は、Kerberosで保護されたクラスタ上にのみインストールできることに注意してください。

Navigator Key Trustee (キーおよび証明書を管理するサービス)をOracle Big Data Appliance外部の別のサーバー上に設定することをお薦めします。

HDFS透過的暗号化のインストールおよび有効化の手順は、My Oracle Supportの次のMOSドキュメントを参照してください。

タイトル	MOSドキュメントID
How to Setup Highly Available Active and Passive Key Trustee Servers on BDA V4.4 Using 5.5 Parcels	2112644.1 パッケージベースのインストールよりも、このMOSドキュメントで説明されているパーセルを使用したインストールをお薦めします。パーセルに関するClouderaのコメントを参照してください。
How to Enable/Disable HDFS Transparent Encryption on Oracle Big Data Appliance V4.4 with bdacli	2111343.1
How to Create Encryption Zones on HDFS on Oracle Big Data Appliance V4.4	2111829.1

注意:

HDFSでの透過的暗号化またはKerberosのいずれかが無効化されている場合、クラスタ内のHDFSでの透過的暗号化ゾーンに格納されているデータは暗号化されたままとなるため、アクセス不可です。データへのアクセスを復元するには、同じキー・プロバイダを使用してHDFS透過的暗号化を再度有効にします。

関連項目:

暗号化ゾーンにおけるファイルの管理の詳細は、HDFSによる休止状態での暗号化に関するClouderaドキュメント(http://www.cloudera.com)を参照してください。

2.13.5 HTTPS/ネットワーク暗号化について

Big Data ApplianceでのHTTPSネットワーク/暗号化には、次の2つのコンポーネントがあります。

• Web Interface Encryption

  WebインタフェースCloudera Manager、OozieおよびHUEについてHTTPSを構成します。この暗号化は、新しいMammothインストールでは自動的に有効化されるようになりました。現在のインストールでは、bdacliユーティリティを介して有効化できます。この機能ではKerberosが有効化されている必要はありません。

• Encryption for Data in Transit and Services

  この機能には、2つのサブコンポーネントがあります。どちらも、インストール時に構成ユーティリティで有効にしたり、いつでもbdacliユーティリティを使用して有効化/無効化することができるオプションです。どちらの場合もKerberosが有効化されている必要があります。

  • Encrypt Hadoop Services

    これには、HDFS、MapReduceおよびYARNの各Webインタフェース用のSSL暗号化やMapReduceとYARN用の暗号化シャッフルが含まれます。また、これにより、MapReduceおよびYARNロールのWebコンソールへのアクセスの認証も有効化されます。

  • Encrypt HDFS Data Transport

    このオプションにより、DataNodeとクライアントとの間およびDataNode間で転送されるデータの暗号化が有効化されます。

HTTPS/ネットワーク暗号化は、クラスタごとに有効化および無効化されます。『Oracle Big Data Applianceオーナーズ・ガイド』の構成ユーティリティの説明には、クラスタを作成するときに、HadoopサービスおよびHDFSデータ・トランスポートの暗号化を有効化するための設定が含まれています。bdacliユーティリティのリファレンス・ページ(または『Oracle Big Data Applianceオーナーズ・ガイド』)には、HTTPS/ネットワーク暗号化コマンドライン・オプションについて記載されています。

関連項目:

CDHクラスタを保護するためにKerberosを使用する方法の概要は、「Oracle Big Data Applianceへのユーザー・アクセスのサポート」 を参照してください。

保存されているHadoopデータを対象としたOracle Big Data Applianceセキュリティの詳細は、「HDFSでの透過的暗号化について」を参照してください。

Cloudera ManagerにおけるHTTPS通信およびCDHにおけるネットワークレベルの暗号化の詳細は、Clouderaドキュメント(http://www.cloudera.com)を参照してください。

2.13.5.1 Kerberos認証を使用するためのWebブラウザの構成

Webインタフェース暗号化が有効化されている場合、HDFS、MapReduceまたはYARNで暗号化されたWebインタフェースにアクセスする各Webブラウザを、Kerberosを使用して認証するように構成する必要があります。これは、Kerberosを必要としないCloudera Manager、OozieおよびHueの各Webインタフェースでは不要であることに注意してください。

Mozilla Firefox^脚注 3、Microsoft Internet Explorer^脚注 4およびGoogle Chrome^脚注 5でKerberos認証を構成するステップは、次のとおりです。

Mozilla Firefoxを構成するには、次の手順を実行します。

1. ロケーション・バーにabout:configと入力します。

2. about:configページの「検索」ボックスに、network.negotiate-auth.trusted-urisと入力します

3. 「設定名」の下の、network.negotiate-auth.trusted-urisをダブルクリックします。

4. 「文字列を入力してください」ダイアログで、Kerberosによって保護するWebサーバーのホスト名またはドメイン名を入力します。複数のドメインおよびホスト名は、カンマで区切ります。

Microsoft Internet Explorerを構成するには、次の手順を実行します。

1. ローカル・イントラネット・ドメインを構成します。

   1. Microsoft Internet Explorerを開き、右上隅にある「設定」歯車アイコンをクリックします。「インターネット オプション」を選択します。

   2. 「セキュリティ」タブを選択します。

   3. 「ローカル イントラネット」ゾーンを選択して、「サイト」をクリックします。

   4. 最初の2つのオプション「ほかのゾーンにないローカル (イントラネット) のサイトをすべて含める」および「プロキシ サーバーを使用しないサイトをすべて含める」を選択します。

   5. 「ローカル イントラネット」ダイアログ・ボックスで「詳細設定」をクリックし、一度に1つずつ、Kerberosで保護されたドメインの名前をWebサイトのリストに追加します。

   6. 「閉じる」をクリックします。

   7. 「OK」をクリックして構成変更を保存してから、もう一度「OK」をクリックし、「インターネット オプション」パネルを終了します。

2. Microsoft Internet Explorer用のイントラネット認証を構成します。

   1. 右上隅にある「設定」歯車アイコンをクリックします。「インターネット オプション」を選択します。

   2. 「セキュリティ」タブを選択します。

   3. 「ローカル イントラネット」ゾーンを選択して、「レベルのカスタマイズ...」ボタンをクリックし、「セキュリティ設定 - ローカル イントラネット ゾーン」ダイアログ・ボックスを開きます。

   4. 「ユーザー認証」オプションまで下方向にスクロールして、「イントラネット ゾーンでのみ自動的にログオンする」を選択します。

   5. 「OK」をクリックして、変更内容を保存します。

Google Chromeを構成するには、次の手順を実行します。

Microsoft Windowsを使用している場合、「コントロール パネル」を使用して、「インターネット オプション」ダイアログ・ボックスに移動します。必要な構成変更は、Microsoft Internet Explorerについて前述した内容と同じです。

^脚注 6またはLinuxでは、 --auth-server-whitelistパラメータをgoogle-chromeコマンドに追加します。たとえば、ChromeをLinuxプロンプトから実行するには、google-chromeコマンドを次のように実行します

 google-chrome --auth-server-whitelist = "hostname/domain"

注意:

Microsoft Windowsでは、WindowsユーザーはKerberosレルムのユーザーである必要があり、有効なチケットを処理する必要があります。これらの要件が満たされない場合は、Kerberosで保護されたWebインタフェースにアクセスしようとすると、ブラウザにHTTP 403が表示されます。

2.13.6 Oracle Big Data Applianceで使用されるポート番号

次の表に、CDH用のポート番号の他に使用される可能性のあるポート番号を示します。

特定のサーバー上で使用されるポート番号を確認するには、次の手順を実行します。

1. Cloudera Managerで、ページ上部にある「Hosts」タブをクリックして、「Hosts」ページを表示します。

2. 「Name」列でサーバーのリンクをクリックすると、その詳細ページが表示されます。

3. 「Ports」セクションまで下方向にスクロールします。

関連項目:

CDHのポート番号の詳細なリストは、次に示すClouderaのWebサイトを参照してください。

https://www.cloudera.com/documentation/enterprise/5-15-x/topics/cm_ig_ports.html

表2-15 Oracle Big Data Applianceのポート番号

サービス	ポート
自動サービス・モニター(ASM)	30920
MySQL Database	3306
Oracle Data Integratorエージェント	20910
Oracle NoSQL Database管理	5001
Oracle NoSQL Databaseプロセス	5010から5020
Oracle NoSQL Database登録	5000
ポート・マップ	111
Puppetマスター・サービス	8140
Puppetノード・サービス	8139
rpc.statd	668
ssh	22
xinetd (サービス・タグ)	6481

2.13.7 Puppetのセキュリティについて

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アドレスに解決されます。

2.14 Oracle Big Data Applianceの監査

注意:

Audit Vault and Database FirewallはOracle Big Data Applianceで使用できなくなりました。監視にはCloudera Navigatorを使用することをお薦めします。

2.15 オラクル社カスタマ・サポートに提供する診断情報の収集

CDHの問題のトラブルシューティングを行うために、Oracleサポートのアドバイスが必要な場合は、まずbdadiagユーティリティをcmオプションを指定して使用し、診断情報を収集してください。

診断情報を収集するには、次の手順を実行します。

1. Oracle Big Data Applianceサーバーにrootとしてログインします。

2. 少なくともcmオプションを指定してbdadiagを実行します。必要に応じてコマンドに他のオプションを含めることができます。bdadiagの構文の詳細は、『Oracle Big Data Applianceオーナーズ・ガイド』を参照してください。

   # bdadiag cm

   コマンド出力によって、診断ファイルの名前と場所が識別されます。

3. My Oracle Support (http://support.oracle.com)へ移動します。

4. サービス・リクエスト(SR)を開きます(まだ開いていない場合)。

5. SRにbz2ファイルをアップロードします。ファイルのサイズが大きすぎる場合は、sftp.oracle.comにアップロードしてください(次の手順を参照)。

診断情報をftp.oracle.comにアップロードするには、次の手順を実行します。

1. SFTPクライアントを開き、sftp.oracle.comに接続します。ポート2021とリモート・ディレクトリ/support/incoming/targetを指定します(targetは、Oracle Supportにより指定されたフォルダ名です)。

2. Oracle Single Sign-Onのアカウントとパスワードでログインします。

3. 診断ファイルを新しいディレクトリにアップロードします。

4. このフル・パスおよびファイル名でSRを更新します。

関連項目:

My Oracle Support Note 549180.1

http://support.oracle.com

---

脚注の説明

脚注3: Mozilla FirefoxはMozilla Foundationの登録商標です。
脚注4: Microsoft Internet ExplorerはMicrosoft社の登録商標です。
脚注5: Google ChromeはGoogle社の登録商標です
脚注6: Mac OSはApple社の登録商標です。