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 SQLの管理

• 概要

• 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/5-15-x/topics/hue.html

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

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

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

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

• 未構成のソフトウェア

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

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

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

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

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

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

「図3-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のライセンス情報ユーザー・マニュアルに記載されているガイドラインに従ってください。

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

3.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」をクリックして現在の設定を変更します。

3.6 CDHクラスタについて

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

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

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

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

注意:

古いバージョンからリリース5.0にアップグレードされた複数ラックのクラスタでは、一部の重要なサービスが2番目のラックでホストされる現在の複数ラック・レイアウトが維持されます。Oracle Big Data Applianceソフトウェア・ユーザーズ・ガイド リリース4.13の例を参照してください。

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

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

ノード1	ノード2	ノード3	ノード4	ノード5 - 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高可用性が有効化されている場合、Node04および顧客が選択した別のノード(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つしかないため、障害に対して脆弱です。

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の自動フェイルオーバーをサポートしているプロセス間の関係を示しています。

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

「図3-7 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-8 Oracle Big Data ApplianceでのResourceManagerの自動フェイルオーバー

「図3-8 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 Kafkaクラスタについて

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

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

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

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

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

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

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

注意:

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

表3-3 シングル・ラック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	—

表3-4 マルチラック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	—

表3-5 マルチラック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番目のラックのみ)	—	—	—

表3-6 マルチラック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	—	—

表3-7 マルチラック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番目のラックのみ)	—	—	—

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

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

注意:

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

3.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データ・パーティションが含まれます。

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

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

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

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

ディスク1および2 (OS)	ディスク3 – 12 (データ)
10 TBドライブ: ディスク/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ドライブ: ディスク/dev/sdeから/dev/sdn: Number Start End Size File system Name Flags 1 1049kB 9796GB 9796GB ext4 ext4
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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ノード名	重要な機能
第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つの重要なノードが作成されます。4つ以上のノードを持つCDHクラスタのラック1のサービス・ロケーションを参照してください

マルチラック・クラスタでは、第2NameNodeノードと第2ResourceManagerノードは第2ラックの最初の2つのノードに移動されます。クラスタの追加ラックのサービス・ロケーションを参照してください。

3.9.3 第1 NameNodeノード

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

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

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

3.9.4 第2 NameNodeノード

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

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

3.9.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.9.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 SQLおよびOracle Big Data Connectorsの大部分はHive表にアクセスできますが、このノードに障害が発生した場合、この表は使用できません。

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

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

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

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

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

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

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

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

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

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

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

3.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を使用してそれらを新しいノードで再構成します。

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

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

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

• 前提条件

• Oracle Big Data Applianceの停止

• Oracle Big Data Applianceの起動

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

3.11.2 Oracle Big Data Applianceの停止

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

注意:

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

• Oracle Enterprise Managerエージェント

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

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

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

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

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

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

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

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

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

3.11.2.5 サーバーの停止

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

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

   # dcli -g filename shutdown -h now

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

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

   # shutdown -h now

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

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

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

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

3.11.3 Oracle Big Data Applianceの起動

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

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

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

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

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

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

3.12 Oracle Big Data SQLの管理

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

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

3.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のライセンス契約には含まれていません。

3.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のインストールと構成に関する詳細な情報が記載されています。

3.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サービスの構成ページを示します。

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

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

関連項目:

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

3.13 Oracle Big Data Applianceの監査

注意:

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

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

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