3 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 Applianceの監査

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

3.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プラグイン機能に関する最新情報についてお問い合せください。

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

Oracle Enterprise Manager Webインタフェースを開いてログインし、ターゲット・クラスタを選択すると、次の主要領域へドリルダウンできます。

• インフィニバンド・ネットワーク: インフィニバンド・スイッチとポートのネットワーク・トポロジとステータス。図3-1を参照してください。

• Hadoopクラスタ: HDFS、MapReduceおよびZooKeeperのソフトウェア・サービス。

• Oracle Big Data Applianceラック: サーバー・ホスト、Oracle Integrated Lights Out Manager (Oracle ILOM)サーバー、配電ユニット(PDU)、イーサネット・スイッチなどのハードウェア・ステータス。

次の図は、クラスタ・ホームページの一部を示しています。

図3-1 Oracle Enterprise Managerの「YARN」ページ

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

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

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

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

関連項目:

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

3.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の監視および診断情報についての詳細が示されています。

3.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のホームページを示します。

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

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

3.2.2 管理タスクの実行

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

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

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

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

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

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

• HDFS

• Hive

• Hue

• Oozie

• YARN

• ZooKeeper

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

ノート:

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

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

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

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

3.3.1 MapReduceジョブの監視

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

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

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

  http://bda1node03.example.com:8088

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

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

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

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

3.3.2 HDFSの状態の監視

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

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

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

  http://bda1node01.example.com:50070

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

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

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

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

3.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を示します。

図3-5 Hive Query Editor

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

関連項目:

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

https://www.cloudera.com/documentation/enterprise/6/6.0/topics/hue.html

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

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

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

• 未構成のソフトウェア

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

3.5.1 未構成のソフトウェア

ご使用の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

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

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

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

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

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

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

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

3.6 CDHクラスタについて

クラスタ内のサービスの場所は、クラスタの構成によって多少異なります。

通常、Mammothインストーラでデプロイされたロールのデコミッションまたは削除はサポートされません。スレーブ・ロールの場合は許容できることがあります。ただし、ロールはCloudera Managerから完全に削除する必要があります。また、ロールを削除すると、パフォーマンスが低下したり、ストレージが削減されたりする場合があります。

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

• 4つ以上のノードを持つCDHクラスタのラック1のサービス・ロケーション

• クラスタの追加ラックのサービス・ロケーション

• About MapReduce

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

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

3.6.1 3ノードの開発クラスタのサービス

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

注意:

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

表3-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	-

3.6.2 4つ以上のノードを持つCDHクラスタのラック1のサービス・ロケーション

リリース5.1以降では、Oracle Big Data Applianceの新規インストールで、マルチラック・クラスタ内のサービスの分散が変更されました。4つのマスター・ノード(およびホストするサービス)は、クラスタの最初のラックにすべて配置されるようになりました。以前のリリースでは、一部の重要なサービスがマルチラック・クラスタの2番目のラックでホストされていました。

ノート:

古いバージョンからリリース5.1にアップグレードされた複数ラックのクラスタでは、一部の重要なサービスが2番目のラックでホストされる現在の複数ラック・レイアウトが維持されます。

次の表は、CDHクラスタの最初のラックのサービスを示しています。Node1はクラスタ内の最初のサーバーで、nodennはクラスタ内の最後のサーバーです。このサービス・レイアウトは、シングル・ラック・クラスタとマルチラック・クラスタの最初のラックで同じです。

表3-2 クラスタの最初のラックでのサービス・ロケーション

Node1	Node2	Node3	Node4	Node5から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	Big Data Manager (BDM-proxyおよびBDM-notebookを含む)	Oozie	-
JournalNode	JournalNode	JournalNode	-	-
-	MySQL Backup	MySQL Primary	-	-
NameNode	NameNode	Navigator監視サーバーおよびNavigatorメタデータ・サーバー	-	-
NodeManager (8ノード以下のクラスタ内)	NodeManager (8ノード以下のクラスタ内)	NodeManager	NodeManager	NodeManager
Sentry Server(有効化されている場合)	Sentry Server(有効化されている場合)	SparkHistoryServer	Oracle Data Integratorエージェント	-
Hive Metastore	HttpFS	-	HiveメタストアおよびHiveServer2	-
ZooKeeper	ZooKeeper	ZooKeeper	Hive WEbHCatサーバー	-
Hueサーバー	-	JobHistory	Hueサーバー	-
Hueロード・バランサ	-	Hueロード・バランサ	-	-
アクティブNavigator Key Trustee Server (HDFS透過的暗号化が有効化されている場合)	パッシブNavigator Key Trustee Server (HDFS透過的暗号化が有効化されている場合)	ResourceManager	ResourceManager	-
Kerberos KDC (MIT Kerberosが有効化され、BDA上のKDCが使用されている場合)	Kerberos KDC (MIT Kerberosが有効化され、BDA上のKDCが使用されている場合)	-	-	-
Kerberosが有効な場合: Hue Kerberos Ticket Renewer、Key Trustee KMS Key Management Serverプロキシ、Key Trustee Serverアクティブ・データベース	Kerberosが有効な場合: Key Trustee KMS Key Management Serverプロキシ、Key Trustee Serverパッシブ・データベース	-	Kerberosが有効な場合: Hue Kerberos Ticket Renewer	-

ノート:

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

3.6.3 クラスタの追加ラックのサービス・ロケーション

ノート:

このレイアウトは以前のリリースから変更されています。すべての重要なサービスが、クラスタの最初のラックで実行されるようになりました。

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

ラック2および追加のラックのすべてのノードで実行されるサービスは、ラック1のノード5以降で実行されるサービスと同じです。

• Cloudera Manager Agent
• DataNode
• NodeManager (8ノード以下のクラスタの場合)

3.6.4 MapReduceについて

Yet Another Resource Negotiator (YARN)は、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/

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

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

Oracle Big Data Applianceの現在のバージョンのCloudera's Distribution including Apache Hadoopでは、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の自動フェイルオーバーをサポートしているプロセス間の関係を示しています。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ノート:

マルチラック・クラスタでは、一部の重要なサービスが第2ラックの第1サーバーで実行されます。クラスタの追加ラックのサービス・ロケーションを参照してください。

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

X8、X7、X6、X5およびX4サーバー・モデル用の論理ディスク・パーティションのレイアウトを次に示します。

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

Big Data Applianceのディスク・パーティショニングで、これまでに行われた重要な変更には次のものがあります。

• X7: BIOSのかわりにEFIを使用するように切り替わり、USBが2つのSSDに交換されました
• Oracle Linux 7: スワップ・パーティションが削除されました。
• X8: 新しいパーティションが追加されます。

次の表で、Linuxのディスクまたはパーティションのデバイス名(/dev/sdc、/dev/sdc1など)が変動することがあります。これらは起動時にカーネルによって選択されるため、ディスクが削除されてから再び追加されると変更される可能性があります。

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

ディスク1および2 (OS)	ディスク3 – 12 (データ)
14 TBのドライブ(Big Data Appliance X8) ディスク/dev/sda : Number Start End Size File system Name Flags 1 1049kB 201MB 200MB fat16 EFI System Partition boot 2 201MB 701MB 500MB ext4 ext4 raid 3 701MB 1049GB 1049GB ext4 raid 4 1049GB 11.5TB 10.5TB ext4 ext4 5 11.5TB 13.7TB 2180GB ext4 ext4 ディスク/dev/sdb: Number Start End Size File system Name Flags 1 1049kB 201MB 200MB fat16 fat32 2 201MB 701MB 500MB ext4 ext4 raid 3 701MB 1049GB 1049GB ext4 raid 4 1049GB 11.5TB 10.5TB ext4 ext4 5 11.5TB 13.7TB 2180GB ext4 ext4	14 TBのドライブ(Big Data Appliance X8) ディスク/dev/sdcから/dev/sdlへ: Number Start End Size File system Name Flags 1 17.4kB 10.5TB 10.5TB ext4 ext4 2 10.5TB 13.7TB 3229GB ext4 ext4
10 TBのドライブ(Big Data Appliance X7) ディスク/dev/sdc: Number Start End Size File system Name Flags 1 1049kB 201MB 200MB fat16 EFI System Partition boot 2 201MB 701MB 500MB ext4 raid 3 701MB 1049GB 1049GB ext4 raid 4 1049GB 9796GB 8747GB ext4 ext4 ディスク/dev/sdd: Number Start End Size File system Name Flags 1 1049kB 201MB 200MB fat16 fat32 2 201MB 701MB 500MB ext4 raid 3 701MB 1049GB 1049GB ext4 raid 4 1049GB 9796GB 8747GB ext4 ext4	10 TBのドライブ(Big Data Appliance X7) ディスク/dev/sdeから/dev/sdn: Number Start End Size File system Name Flags 1 1049kB 9796GB 9796GB ext4 ext4
8 TBのドライブ(Big Data Appliance X6およびX5) 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のドライブ(Big Data Appliance X6およびX5) Number Start End Size File system Name Flags 1 1049kB 7864GB 7864GB ext4 primary
4 TBのドライブ(Big Data Appliance X4) 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のドライブ(Big Data Appliance X4) Number Start End Size File system Name Flags 1 1049kB 4000GB 4000GB ext4 primary

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

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

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

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

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

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

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

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

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

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

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

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

重要なサービスは次のようにホストされます。各ノードのサービスの完全なリストについては、4つ以上のノードを持つCDHクラスタのラック1のサービス・ロケーションを参照してください。

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

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

3.8.3 第1 NameNodeノード

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

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

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

3.8.4 第2 NameNodeノード

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

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

3.8.5 第1 ResourceManagerノード

第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データベースを使用しています。データは自動的にレプリケートされますが、マスター・データベース・サーバーが停止していると、それにはアクセスできません。

3.8.6 第2 ResourceManagerノード

第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 Connectorsの多くは、Hive表にアクセスできますが、このノードが動作していない場合は使用できません。

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

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

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

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

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

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

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

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

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

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

3.9.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ノードにインストールされます。

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

障害が発生したクリティカル・ノードに対処するための手順は、重要なサービスを他のノードに移行することです。

重要なサービスを障害が発生したノードから別のノードに移行した後に、障害の発生したノードをクラスタに再統合するためのオプションがいくつかあります。

• ノードの再プロビジョニング

  この手順では、ノードがDataNodeとして動作するために必要なすべてのソフトウェアを再インストールします。再プロビジョニングは、修復不能だったために交換されたノードの場合の唯一のオプションです。

• ノードの再コミッション

  障害が発生したしたクリティカル・ノードをDataNodeロールが機能する程度まで修復でき、DataNodeロールに障害を与える可能性のある問題が解決されている場合は、ノードを再プロビジョニングするかわりにノードを再コミッションすることによって、時間を節約できます。再コミッション処理ははるかに速く実行されます。ノードがDataNodeとして再統合されますが、完全な再インストールは実行されず、イメージを変更する必要もありません。ノードのデコミッショニングと逆の処理が行われます。デコミッショニングではノードが隔離され、再コミッションではノードが隔離から戻されます。

  ノート:

  障害が発生したNode1を再コミッションする前に、特別な手順を実行する必要があります。この項の最後にあるNode1を再コミッションするための準備ステップを参照してください。

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

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

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

   bdacli admin_cluster migrate node_name

   コマンドが完了すると、障害が発生したノードがデコミッションされ、以前の非クリティカル・ノードでサービスが実行されるようになります。

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

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

5. Mammothノードでrootとして、修理または交換したサーバーを非クリティカル・ノードとして再プロビジョニングまたは再コミッションします。node_nameには、移行されたノードと同じ名前(「bda1node02」など)を使用します。
   • ノードを再プロビジョニングするには、次のコマンドを実行します。

     ノート:

     ノードを再プロビジョニングする場合は、ソフトウェアに他の問題がないことを確認するために、まずノードのイメージを変更することをお薦めします(ただし、必須ではありません)。

     # bdacli admin_cluster reprovision <node_name>

   • ノードを再コミッションするには、次のコマンドを実行します。

     # bdacli admin_cluster reprovision <node_name>

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

   bdacli admin_cluster reprovision node_name

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

Node1のみを再コミッションする場合の準備ステップ

障害が発生した(および修復された) Node1を再コミッションする前に、次のステップを実行します。

1. Mammothロールの再配置先を決定します。通常、MammothはNode1で動作するため、このノードで障害が発生した場合は、Mammothロールが別のノードに転送される必要があります。他のクリティカル・ノードが使用されることが回避され、かわりに使用可能な最初のDataNodeが選択されることが理想的です。
2. クラスタの各ノードで、次の手順を実行します。
   1. /opt/oracle/bda/install/state/config.jsonを更新します。Mammothロールをホストする予定のノードを指すようにMAMMOTH_NODEを変更します。
   2. /opt/oracle/bda/cluster-hosts-infinibandを更新してNode1を追加します。
3. Mammothロールをホストする予定のノードで、次のようにします。

   # setup-root-ssh -C 

4. SSHを使用して、各ノードにrootとしてログオンし、/opt/oracle/bda/install/state/config.jsonを編集します。QUARANTINED配列(QUARANTINED_POSNSおよび QUARANTINED_HOSTS)からNode1を削除します。
5. Mammothロールをホストする予定のノードで、次のようにします。
   1. mammoth -zを実行します。

      このノードが新しいMammothノードになりました。

   2. クラスタ内の各ノードにログオンし、/opt/oracle/bda/install/state/config.jsonで、QUARANTINED配列にNode1を再入力します。
6. これでNode1を再コミッションできるようになりました。Mammothノードで、次のコマンドを実行します。

   # bdacli admin_cluster recommission node0

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

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

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

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

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

   bdacli admin_cluster decommission node_name

   Configuraton Managerで、ノードがデコミッションされていることを確認します。

3. 障害が発生したノードをデコミッションした後の次のステップは、次の2つの条件のうちどれが真であるかによって異なります。
   • ノードは再イメージ化せずに修復できます。
   • ノードを交換する必要があるか、ノードを修復できるものの再イメージ化が必要です。

     障害が発生したノードにアクセスできない場合、またはOSが破損している場合は、再イメージ化する必要があります。

4. 1. ノードが交換されるか再イメージ化する必要がある場合は、My Oracle Supportのドキュメント1485745.1の手順に従います。このドキュメントには、Big Data Applianceのすべてのリリースについて、イメージング手順へのリンクが示されています。
      再イメージ化の後、ノードを再プロビジョニングします。

      # bdacli admin_cluster reprovision node_name

      その後、ノードは再コミッションの準備が整います。

   2. 既存のノードを再イメージ化せずに修復できる場合は、再コミッションします。再プロビジョニングは不要です。

   いずれの場合も、ノードを再コミッションするには、rootとしてMammothノードにログインし、次のbdacliコマンドを実行します。node_nameには、デコミッションされたノードと同じ名前を使用します。

   bdacli admin_cluster recommission node_name

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

関連項目:

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

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

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

• 前提条件

• Oracle Big Data Applianceの停止

• Oracle Big Data Applianceの起動

3.10.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オーナーズ・ガイド』を参照してください。

3.10.2 Oracle Big Data Applianceの停止

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

ノート:

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

• Oracle Enterprise Managerエージェント

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

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

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

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

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

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

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

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

図3-8 HDFSサービスの停止

「図3-8 HDFSサービスの停止」の説明

3.10.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コンソールを使用してアクセスすることはできません。

3.10.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

3.10.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ディレクトリをディスマウントします。

3.10.2.5 サーバーの停止

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

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

   # dcli -g filename shutdown -h now

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

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

   # shutdown -h now

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

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

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

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

3.10.3 Oracle Big Data Applianceの起動

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

3.10.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

3.10.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」を再びクリックします。図3-8を参照してください。

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

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

3.10.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]

3.11 Oracle Big Data Applianceの監査

注意:

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

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

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