3 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)、イーサネット・スイッチなどのハードウェア・ステータス。
次の図は、クラスタ・ホームページの一部を示しています。
Oracle Enterprise Managerを使用してOracle Big Data Applianceを監視するには、次の手順を実行します。
-
プラグインをダウンロードしてインストールします。『Oracle Enterprise Manager System Monitoring Plug-inインストレーション・ガイドfor Oracle Big Data Appliance』 を参照してください。
-
管理ユーザーとしてOracle Enterprise Managerにログインします。
-
「ターゲット」メニューから「ビッグ・データ・アプライアンス」を選択し、ビッグ・データ・ページを表示します。Oracle Enterprise Managerによって検出済のターゲットの全体的なステータスが表示されます。
-
詳細ページを表示するターゲット・クラスタを選択します。
-
ターゲット・ナビゲーション・ツリーを展開し、コンポーネントを表示します。すべてのレベルで情報を使用可能です。
-
ツリーでコンポーネントを選択し、ホーム・ページを表示します。
-
表示を変更するには、メイン表示領域の左上部にあるドロップダウン・メニューから項目を選択します。
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を使用するには、次の手順を実行します。
-
ブラウザを開き、次のようにURLを入力します。
この例で、
bda1はアプライアンス名、node03はサーバー名、example.comはドメイン、7180はデフォルトのポート番号(それぞれCloudera Managerで使用)を示します。 -
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のステータスの監視
-
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.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.2 HDFSの状態の監視
クラスタの最初の2つのノードでDFS状態ユーティリティを使用することで、Hadoopファイル・システムの状態を監視できます。
HDFSを監視するには、次の手順を実行します。
-
ブラウザを開き、次のようにURLを入力します。
http://bda1node01.example.com:50070
この例では、
bda1はラックの名前、node01はdfshealthユーティリティが実行されているサーバーの名前、50070はユーザー・インタフェースのデフォルトのポート番号です。
図3-3に、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を使用するには、次の手順を実行します。
-
Cloudera Managerにログインし、「Home」ページのhueサービスをクリックします。
-
クイック・リンクの下にあるhueページで、
「Hue Web UI」をクリックします。 -
ブラウザでHueを直接開けるように、HueのURLをブックマークします。次にURLの例を示します。
http://bda1node03.example.com:8888
-
Hue資格証明を使用してログインします。
Hueアカウントがまだ作成されていない場合は、次の資格証明を使用してデフォルトのHue管理者アカウントにログインします。
-
ユーザー名:
admin -
パスワード:
cm-admin-password
ここで、
cm-admin-passwordは、Cloudera Manager管理ユーザーのクラスタがアクティブ化されたときに指定されたパスワードです。この後で、他のユーザーと管理者アカウントを作成できます。 -
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を使用して追加する必要があります。
サービスを追加するには、次の手順を実行します。
-
adminユーザーとしてCloudera Managerにログインします。 -
「Home」ページで、左側のパネルのクラスタ・メニューを展開し、「Add a Service」を選択して「Add Service」ウィザードを開きます。最初のページには、追加できるサービスがリストされます。
-
ウィザードのステップに従います。
関連項目:
-
CDHコンポーネントのリストは、次を参照してください。
http://www.cloudera.com/content/www/en-us/products/apache-hadoop/key-cdh-components.html
3.5.2 サービス間でのリソースの割当て
リソース・プールの合計の割合として、リソースをHDFS、YARN、Hiveなどの各サービスに割り当てることができます。Cloudera Managerでは、これらの割合に基づいて推奨されるリソース管理設定が自動的に計算されます。あるサービスに対する高負荷が他のサービスに与える影響が制限されるように、静的サービス・プールはクラスタ上のサービスを切り離します。
サービス間にリソースを割り当てるには、次の手順を実行します。
-
adminとしてCloudera Managerにログインします。 -
ページの上部の「Clusters」メニューを開き、「Resource Management」の下の「Static Service Pools」を選択します。
-
「Configuration」を選択します。
-
ウィザードのステップに従うか、または「Change Settings Directly」をクリックして現在の設定を変更します。
3.6 CDHクラスタについて
クラスタ内のサービスの場所は、クラスタの構成によって多少異なります。
通常、Mammothインストーラでデプロイされたロールのデコミッションまたは削除はサポートされません。スレーブ・ロールの場合は許容できることがあります。ただし、ロールはCloudera Managerから完全に削除する必要があります。また、ロールを削除すると、パフォーマンスが低下したり、ストレージが削減されたりする場合があります。
この項の内容は次のとおりです。
3.6.1 新規クラスタの場合: 高可用性HiveServer2およびOozie
高可用性HiveServer2およびHA Oozieは、新規クラスタに自動的に含まれます。
Big Data Appliance 5.2では、新規クラスタにHA HiveServer2およびHA Oozieが自動的に含まれます。これは新規クラスタにのみ適用されます。
OozieおよびHiveServer2ロールは、各新規クラスタ内の別々のノードで複製されます。ロールのペアごとに、両方のロールが継続的にアクティブになります。トラフィックは、HAProxyロード・バランサを介してルーティングされます。ロード・バランサが単一障害点になるのを防ぐために、ロード・バランサの高可用性を構成するオプションもBig Data Appliance構成生成ユーティリティにあります。HAがロード・バランサ用に構成されている場合、プライマリ・バランサは通常アクティブです。セカンダリ・ロード・バランサは、最初のものに障害が発生した場合にフェイルオーバーを提供するためにのみアクティブ化されます。
Hiveserver2およびOozie HAの機能拡張は、このリリースにアップグレードされた既存のクラスタには追加されません。現時点では、アップグレードされたクラスタでHiveServer2およびOozieを有効にする手動ステップはありません。
HiveServer2およびOozieのキーストアおよびトラスト・ストアの場所の変更
HiveServer 2およびOozieの高可用性の導入とともに、Big Data Appliance 5.2以降はこれらのロールのキーストアおよびトラストストアの場所が変更されていることに注意してください。このトピックの最後に示すように、構成マネージャにこれが表示されます。
- HiveServer2 TLS/SSL Server JKS Keystore File LocationHiveServer2 TLS/SSL Server JKS Keystore File Location:
/opt/cloudera/security/pki_load_balancer/node.jks - HiveServer2 TLS/SSL Client Truststore File:
/opt/cloudera/security/pki_load_balancer/kpoklkd.truststore
ノート:
これらの変更は、新規クラスタにのみ適用されます。アップグレードされたクラスタは、5.2より前の元のキーストアおよびトラストストア・パスを保持します。構成マネージャの次の例は、キーストアおよびトラストストアの新しい場所を示しています。また、HiveServer2およびOozieトラフィックを処理するロード・バランサのアドレスも表示されます。
3.6.1.1 HiveServer2およびOozieロード・バランサのHAの構成
HiveServer2およびOozieの高可用性では、ロード・バランサは潜在的な単一障害点のままです。ただし、ロード・バランサの高可用性を提供するオプションもあります。
HiveServer2およびOozieロード・バランサのHAをサポートする仮想IPアドレス
ノート:
ロード・バランサのHAを構成するための前提条件は2つあります。- ロード・バランサのパブリック仮想IPアドレスを指定します。
- 厳密なファイアウォール・ルールがある環境では、これらのルールがマルチキャスト・アドレス224.0.0.18およびVRRPプロトコルの実行を許可する必要があります。
アプライアンスにMammothインストールを事前構成するときに、ロード・バランサの高可用性を設定するよう選択できます。ロード・バランサのHAをサポートするには、パブリック仮想IPアドレスを指定する必要があります。これは、アクティブなロード・バランサに自動的に割り当てられるフローティングIPアドレスとして使用されます。フェイルオーバー・イベントでは、障害が別のノードのロード・バランサに発生したロード・バランサから仮想IPアドレスが再割当てされ、この2番目のロード・バランサがHiverServer2およびOozieトラフィックを引き継ぐためにアクティブ化されます。通常の状態では、アクティブなロード・バランサはクラスタのNode02にあり、非アクティブなロード・バランサはNode01にあります。ロード・バランサは実際にはすべてのノードにインストールされますが、1つのノードでのみアクティブで、他のすべてのノード上で停止されます。
Oracle Big Data Appliance構成生成ユーティリティに、ロード・バランサの仮想IPアドレスを追加できるフィールドが含まれるようになりました。また、IPアドレスの有効なホスト名も指定します。
重要:
仮想IPアドレスが指定されていない場合、HiverServer2およびOozieトラフィックを処理するロード・バランサのフェイルオーバーはありません。そのため、ロード・バランサまたはノード自体に障害が発生した場合は、障害が発生したロード・バランサからこれらのサービスへの接続を、HiveServer2またはOozieインスタンスのいずれかへの直接接続に手動で変更する必要があります。また、この状況では、エントリ・ポイントがロード・バランサを経由しているため、すべてのmammoth -cテストは失敗します。
Big Data Applianceオーナーズ・ガイドのOracle Big Data Appliance構成生成ユーティリティの使用を参照してください。
3.6.2 3ノードの開発クラスタのロール
Oracle Big Data Applianceは、開発目的で3ノード・クラスタを使用できます。
注意:
3ノード・クラスタは、すべてのノードがマスター・ノードであるため、一般に本番環境には適していません。これにより、高可用性に制約が課されます。本番環境でお薦めされる最小のクラスタ・サイズは5ノードです。ノート:
次の表では、新規クラスタにのみ存在するHA HiveServer2およびOozieサポートの新しいロールが斜体フォントで強調表示され、先頭にアスタリスクが付いています。これらの強調表示されたロールは、アップグレードされたクラスタには存在しません。表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 |
| 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 | - |
| *Oozie | Oozie | - |
| *HiveServer2 | HiveServer2 | - |
| *HAProxyロード・バランサ(停止) | *HAProxyロード・バランサ(開始) | - |
3.6.3 4つ以上のノードを持つCDHクラスタのラック1のロール・ロケーション
4つのマスター・ノードおよびホストするロールは、クラスタの最初のラックにすべて配置されるようになりました。以前のリリースでは、一部の重要なロールがマルチラック・クラスタの2番目のラックでホストされていました。
古いバージョンからリリース5.2にアップグレードされた複数ラックのクラスタでは、一部の重要なロールが2番目のラックでホストされる現在の複数ラック・レイアウトが維持されます。
次の表は、CDHクラスタの最初のラックのロールを示しています。Node1はクラスタ内の最初のサーバーで、Nodennはクラスタ内の最後のサーバーです。このサービス・レイアウトは、シングルラック・クラスタとマルチラック・クラスタの最初のラックで同じです。
ノート:
Big Data Appliance 5.2では、新規クラスタには高可用性OozieとHiveServer2、およびこれらのサービスのトラフィックを管理するためのHAProxyロード・バランサが含まれます。これらのサービスの新しいHAロールはNode1です。ロード・バランサはNode2にあります。これは新規クラスタにのみ適用されます。アップグレードされたクラスタには、これらのロールは含まれません。HA OozieおよびHA Hiveserver2はアップグレードされたクラスタ上に存在せず、HAProxyロード・バランサも存在しません。次の表では、新規クラスタにのみ存在するこれらのロールは斜体フォントで表示され、アスタリスクでマークされています。
表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を含む) |
- |
- |
|
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 Metastore |
- |
|
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* | - | - | Oozie | - |
| HiveServer2* | - | - | HiveServer2 | - |
| HAProxy (停止)* | HAProxy * | - | - | - |
Mammothインストールの構成の詳細を提供するBig Data Appliance構成ユーティリティでは、クラスタ内の2番目のHAProxyインスタンスに仮想IPアドレスを指定した場合、ロード・バランサ自体の高可用性を実装できます。仮想IPアドレスが指定されている場合、クラスタが起動されると、Node2でHAProxyインスタンスがstart状態になり、Node1のインスタンスがstop状態になります。なんらかの理由でNode2のインスタンスがstopに移行すると、Node1のインスタンスが起動されます。
ノート:
Oozie高可用性が有効化されている場合、Node4および顧客が選択した別のノード(ResourceNodeが望ましい)上にOozieサーバーがホストされます。
3.6.4 クラスタの追加ラックのロール・ロケーション
ノート:
このレイアウトは以前のリリースから変更されています。すべての重要なロールは、クラスタの最初のラックで実行されます。ラック2および追加のラックのすべてのノードで実行されるロールは、ラック1のNode5以降で実行されるロールと同じです。
- Cloudera Manager Agent
- DataNode
- NodeManager (8ノード以下のクラスタの場合)
3.6.5 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.6 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.7 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.7 Oracle NoSQL Databaseクラスタについて
Oracle NoSQL Databaseクラスタにはクリティカル・ノードがなく、ストレージ・ノードは3倍にレプリケートされるため、クリティカルな障害のリスクが最小限に抑えられます。管理サービスは、レプリケーション・ファクタと同じ数のノードに分散されます。管理CLIと管理コンソールを使用して、管理プロセスをホストする任意のノードからクラスタを管理できます。
Mammothをホストするノード(クラスタの第1ノード)に障害が発生した場合、「障害が発生したノードを管理するための前提条件」の再インストールするための手順に従います
障害が発生しているOracle NoSQLノードを修理または交換するには、「障害が発生している非クリティカル・ノードの管理」の手順に従います。
3.8 Kafkaクラスタについて
Kafkaクラスタの重要なサービスは次のとおりです。
-
ノード1: 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 論理ディスク・レイアウト
X7、X6、X5およびX4サーバー・モデル用の論理ディスク・パーティションのレイアウトを次に示します。
すべてのドライブ構成で、オペレーティング・システムはディスク1およびディスク2にインストールされます。これら2つのディスクはミラー化されます。これらには、Linuxオペレーティング・システム、インストールされたすべてのソフトウェア、NameNodeデータおよびMySQL Databaseのデータが含まれます。NameNodeおよびMySQLデータベースのデータは、2つのサーバー間でレプリケートされているため、合計で4つのコピーがあります。
- X7: BIOSのかわりにEFIを使用するように切り替わり、USBが2つのSSDに交換されました
- Oracle Linux 7: スワップ・パーティションが削除されました。
次の表で、Linuxのディスクまたはパーティションのデバイス名(/dev/sdc、/dev/sdc1など)が変動することがあります。これらは起動時にカーネルによって選択されるため、ディスクが削除されてから再び追加されると変更される可能性があります。
表3-8 Oracle Big Data Applianceサーバーのディスク・パーティショニング
| ディスク1および2 (OS) | ディスク3 – 12 (データ) |
|---|---|
| 10 TBのドライブ(Big Data Appliance X7) ディスク
/dev/sdc:ディスク/dev/sdd: |
10 TBのドライブ(Big Data Appliance X7) ディスク |
8 TBのドライブ(Big Data Appliance X6およびX5) |
8 TBのドライブ(Big Data Appliance X6およびX5) |
4 TBのドライブ(Big Data Appliance X4) |
4 TBのドライブ(Big Data Appliance X4) |
3.9.2 クリティカルおよび非クリティカルCDHノード
クリティカル・ノードは、クラスタが正常に動作し、すべてのサービスをユーザーに提供するために必要です。これとは対照的に、非クリティカル・ノードに障害が発生しても、クラスタはサービスを失うことなく動作し続けます。
重要なサービスは、初期状態ではクラスタ(マルチラック・クラスタの場合は、最初のラック内のクラスタ)の最初の4つのノードにインストールされます。残りのノード(node05から最大でnode18まで)は重要性の低いサービスのみを実行します。クリティカル・ノードのいずれかでハードウェア障害が発生した場合は、別の非クリティカル・サーバーにサービスを移行できます。たとえば、node02に障害が発生した場合、重要なサービスをnode05に移行できます。表3-2は、最初のラックで実行されるサービスの場所を示したものです。
3.9.2.1 高可用性または単一障害点
一部のサービスには高可用性と自動フェイルオーバーが含まれています。単一障害点を含むサービスもあります。次のリストに、重要なサービスを示します。
-
NameNodes: 高可用性と自動フェイルオーバー
-
ResourceManagers: 高可用性と自動フェイルオーバー
-
MySQL Database: プライマリ・データベースおよびバックアップ・データベースは、バックアップ・データベースに対するプライマリ・データベースのレプリケーションで構成されます。自動フェイルオーバーはありません。プライマリ・データベースに障害が発生すると、クラスタの機能は失われますが、データは失われません。
-
Cloudera Manager: Cloudera Managerサーバーは1つのノードで実行されます。障害が発生すると、Cloudera Manager機能は使用できません。
-
Hueサーバー、Hueロード・バランサ、Sentry、Hiveメタストア(および新規クラスタのみのHiveServer2およびOozie) : 高可用性
-
Oozieサーバー、Oracle Data Integratorエージェント: これらのサービスには冗長性はありません。ノードに障害が発生すると、サービスは使用できません。
3.9.2.2 重要なサービスが実行される場所
重要なサービスは次のようにホストされます。各ノードのサービスの完全なリストについては、4つ以上のノードを持つCDHクラスタのラック1のロール・ロケーションを参照してください。
表3-9 シングル・ラックでの重要なサービスの場所
| ノード名 | 重要な機能 |
|---|---|
|
第1NameNode |
バランサ、フェイルオーバー・コントローラ、JournalNode、NameNode、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.9.3 第1 NameNodeノード
第1NameNodeに障害が発生するか、オフライン(再起動など)になると、第2NameNodeが自動的に引き継いで、クラスタの正常なアクティビティを維持します。
または、第2NameNodeがすでにアクティブな場合は、バックアップなしで動作し続けます。NameNodeが1つのみの場合、クラスタは障害に対して脆弱です。クラスタが、自動フェイルオーバーに必要な冗長性を失うためです。
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 Connectorsの多くは、Hive表にアクセスできますが、このノードが動作していない場合は使用できません。
-
Hue: この管理ツールは、ResourceManagerがダウンしているときには使用できません。
-
Oozie: このワークフローおよび調整サービスはResourceManagerノードで実行され、このノードがダウンしているときには使用できません。
3.10 ハードウェア障害の管理
サーバーに障害が発生した場合、できるかぎり短い中断時間で、クラスタのサービスを保守するステップを実行する必要があります。次の手順で説明するように、bdacliユーティリティを使用して、障害が発生しているサーバーを簡単に管理できます。管理ステップの1つはデコミッショニングと呼ばれます。デコミッショニングは、すべてのサービスのすべてのロールを停止するため、データが失われることはありません。Cloudera Managerでは、CDHノードを終了する前にデコミッションする必要があります。
非クリティカル・ノードに障害が発生しても、サービスが失われることはありません。ただし、CDHクラスタでクリティカル・ノードに障害が発生した場合、「ソフトウェアの可用性に与えるハードウェアの影響」で説明するように、単一障害点を持つサービスは使用できません。次の選択肢のどちらかに決める必要があります。
-
修理が行われるのを待機し、修理が完了するまでサービスが失われた状態が続きます。
-
重要なサービスを別のノードに移動します。これを選択すると、一部のクライアントを新しいノードのアドレスで再構成する必要がある場合があります。たとえば、第2ResourceManagerノード(通常はnode03)で障害が発生した場合、ユーザーはブラウザを新しいノードにリダイレクトしてCloudera Managerにアクセスする必要があります。
サービスの喪失とクライアントを再構成する不便さとを比較検討する必要があります。
3.10.1 障害が発生しているノードを管理するための前提条件
CDHノードまたはOracle NoSQL Databaseノードとして構成されているかどうか、障害が発生しているサーバーまたは障害が発生したサーバーを管理する前に次の操作を実行してください。
-
サービスまたはサーバーを再起動してみます。
-
障害が発生しているノードがクリティカルか非クリティカルかを判断します。
-
障害が発生しているノードが、Mammothがインストールされているノードの場合:
-
CDHノードの場合、障害が発生しているノードと同じクラスタの非クリティカル・ノードを選択します。
NoSQLノードの場合、最初に障害が発生したサーバーを修理または交換し、次のステップに使用します。
-
Mammothバンドルを該当するノードにアップロードして解凍します。
-
次のようなコマンドを使用して、
BDAMammoth-version.runからすべてのファイルを抽出します。# ./BDAMammoth-ol6-4.0.0.run
後で、このノードからすべてのMammoth操作を実行する必要があります。
Mammothユーティリティの詳細は、『Oracle Big Data Applianceオーナーズ・ガイド』を参照してください。
-
障害が発生しているノードを管理するためのこの項の適切な手順に従います。
サービスが以前に移行されていないかぎり、Mammothはクラスタの第1ノードにインストールされます。
-
3.10.2 障害が発生しているCDHクリティカル・ノードの管理
障害が発生したクリティカル・ノードに対処するための手順は、重要なサービスを他のノードに移行することです。
重要なサービスを障害が発生したノードから別のノードに移行した後に、障害の発生したノードをクラスタに再統合するためのオプションがいくつかあります。
- ノードの再プロビジョニング
この手順では、ノードがDataNodeとして動作するために必要なすべてのソフトウェアを再インストールします。再プロビジョニングは、修復不能だったために交換されたノードの場合の唯一のオプションです。
- ノードの再コミッション
障害が発生したしたクリティカル・ノードをDataNodeロールが機能する程度まで修復でき、DataNodeロールに障害を与える可能性のある問題が解決されている場合は、ノードを再プロビジョニングするかわりにノードを再コミッションすることによって、時間を節約できます。再コミッション処理ははるかに速く実行されます。ノードがDataNodeとして再統合されますが、完全な再インストールは実行されず、イメージを変更する必要もありません。ノードのデコミッショニングと逆の処理が行われます。デコミッショニングではノードが隔離され、再コミッションではノードが隔離から戻されます。
ノート:
障害が発生したNode1を再コミッションする前に、特別な手順を実行する必要があります。この項の最後にあるNode1を再コミッションするための準備ステップを参照してください。
障害が発生しているクリティカル・ノードを管理するには、次の手順を実行します。
-
rootとしてMammothノードにログインします。(Mammothがインストールされているノード。通常はNode1)。 -
サービスを非クリティカル・ノードに移行します。(次のnode_nameを、障害が発生しているノードの名前に置換します。)
bdacli admin_cluster migrate node_nameコマンドが完了すると、障害が発生したノードがデコミッションされ、以前の非クリティカル・ノードでサービスが実行されるようになります。
-
ユーザーが必要に応じてクライアントを新しいクリティカル・ノードにリダイレクトできるように、変更をユーザー・コミュニティに通知します。
-
障害が発生したサーバーを修理または交換します。
- Mammothノードで
rootとして、修理または交換したサーバーを非クリティカル・ノードとして再プロビジョニングまたは再コミッションします。node_nameには、移行されたノードと同じ名前(「bda1node02」など)を使用します。- ノードを再プロビジョニングするには、次のコマンドを実行します。
ノート:
ノードを再プロビジョニングする場合は、ソフトウェアに他の問題がないことを確認するために、まずノードのイメージを変更することをお薦めします(ただし、必須ではありません)。# bdacli admin_cluster reprovision <node_name> - ノードを再コミッションするには、次のコマンドを実行します。
# bdacli admin_cluster reprovision <node_name>
- ノードを再プロビジョニングするには、次のコマンドを実行します。
-
rootとしてMammothノードから、修理または交換したサーバーを非クリティカル・ノードとして再プロビジョニングします。node_nameには、移行されたノードと同じ名前(bda1node02など)を使用します。bdacli admin_cluster reprovision node_name -
障害が発生したノードがHBaseやImpalaのようなサービス(Mammothによってインストールされているが、構成されていない状態)をサポートしていた場合、Cloudera Managerを使用してそれらを新しいノードで再構成します。
Node1のみを再コミッションする場合の準備ステップ
障害が発生した(および修復された) Node1を再コミッションする前に、次のステップを実行します。
- Mammothロールの再配置先を決定します。通常、MammothはNode1で動作するため、このノードで障害が発生した場合は、Mammothロールが別のノードに転送される必要があります。他のクリティカル・ノードが使用されることが回避され、かわりに使用可能な最初のDataNodeが選択されることが理想的です。
- クラスタの各ノードで、次の手順を実行します。
/opt/oracle/bda/install/state/config.jsonを更新します。Mammothロールをホストする予定のノードを指すようにMAMMOTH_NODEを変更します。/opt/oracle/bda/cluster-hosts-infinibandを更新してNode1を追加します。
- Mammothロールをホストする予定のノードで、次のようにします。
# setup-root-ssh -C - SSHを使用して、各ノードに
rootとしてログオンし、/opt/oracle/bda/install/state/config.jsonを編集します。QUARANTINED配列(QUARANTINED_POSNSおよびQUARANTINED_HOSTS)からNode1を削除します。 - Mammothロールをホストする予定のノードで、次のようにします。
mammoth -zを実行します。このノードが新しいMammothノードになりました。
- クラスタ内の各ノードにログオンし、
/opt/oracle/bda/install/state/config.jsonで、QUARANTINED配列にNode1を再入力します。
- これでNode1を再コミッションできるようになりました。Mammothノードで、次のコマンドを実行します。
# bdacli admin_cluster recommission node0
3.10.3 障害が発生している非クリティカル・ノードの管理
次の手順を使用して、CDHまたはNoSQLクラスタの障害が発生しているノードを交換します。
障害が発生している非クリティカル・ノードを管理するには、次の手順を実行します。
-
Mammothがインストールされているノード(通常はNode1)に
rootとしてログインします。 -
障害が発生しているノードをデコミッションします。node_nameを、障害が発生しているノードの名前に置換します。
bdacli admin_cluster decommission node_nameConfiguraton Managerで、ノードがデコミッションされていることを確認します。
- 障害が発生したノードをデコミッションした後の次のステップは、次の2つの条件のうちどれが真であるかによって異なります。
- ノードは再イメージ化せずに修復できます。
- ノードを交換する必要があるか、ノードを修復できるものの再イメージ化が必要です。
障害が発生したノードにアクセスできない場合、またはOSが破損している場合は、再イメージ化する必要があります。
-
- ノードが交換されるか再イメージ化する必要がある場合は、My Oracle Supportのドキュメント1485745.1の手順に従います。このドキュメントには、Big Data Applianceのすべてのリリースについて、イメージング手順へのリンクが示されています。
再イメージ化の後、ノードを再プロビジョニングします。
# bdacli admin_cluster reprovision node_nameその後、ノードは再コミッションの準備が整います。
- 既存のノードを再イメージ化せずに修復できる場合は、再コミッションします。再プロビジョニングは不要です。
いずれの場合も、ノードを再コミッションするには、
rootとしてMammothノードにログインし、次のbdacliコマンドを実行します。node_nameには、デコミッションされたノードと同じ名前を使用します。bdacli admin_cluster recommission node_name - ノードが交換されるか再イメージ化する必要がある場合は、My Oracle Supportのドキュメント1485745.1の手順に従います。このドキュメントには、Big Data Applianceのすべてのリリースについて、イメージング手順へのリンクが示されています。
-
ノードがCDHクラスタの一部である場合は、Cloudera Managerにログインし、再コミッションされたノードを探します。HDFS DataNode、YARN NodeManager、および実行中である必要がある他の任意のロールに緑色のステータス・ランプが表示されていることを確認します。されていない場合は、それらを手動で再起動します。
関連項目:
bdacliの構文の詳細は、『Oracle Big Data Applianceオーナーズ・ガイド』を参照してください。
3.11 Oracle Big Data Applianceの停止および起動
この項では、Oracle Big Data Applianceを正常に停止して再起動する方法について説明します。
3.11.1 前提条件
rootアクセス権が必要です。dcliユーティリティを使用できるように、クラスタにパスワードなしSSHが設定されている必要があります。
パスワードなしSSHが設定されていることを確認するには、次の手順を実行します。
-
クラスタの第1ノードに
rootとしてログインします。 -
dcliコマンドを使用して、コマンドが動作していることを確認します。このコマンドは、クラスタ内のすべてのノードのIPアドレスおよびホスト名を返します。# dcli -C hostname 192.0.2.1: bda1node01.example.com 192.0.2.2: bda1node02.example.com . . . -
これらの結果が得られない場合は、クラスタで
dcliを設定します。# setup-root-ssh -C
関連項目:
これらのコマンドの詳細は、『Oracle Big Data Applianceオーナーズ・ガイド』を参照してください。
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)を停止します。
3.11.2.2 Cloudera Manager Serverの停止
次の手順に従って、Cloudera Manager Serverを停止します。
Cloudera Managerを停止した後、Webコンソールを使用してアクセスすることはできません。
3.11.2.4 NFSディレクトリのディスマウント
すべてのノードがnode03でNFSディレクトリを共有しており、追加のディレクトリが存在する場合もあります。NFSディレクトリ(/opt/exportdir)を含むサーバーを使用できない場合、停止しようとすると他のサーバーがハングします。したがって、まずNFSディレクトリをディスマウントする必要があります。
3.11.3 Oracle Big Data Applianceの起動
次の手順に従って、ハードウェアの電源を投入し、Oracle Big Data Appliance上のすべてのサービスを開始します。
3.11.3.1 Oracle Big Data Applianceの電源投入
- 両方のPDUの12個すべてのブレーカのスイッチを入れます。
- 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.12 Oracle Big Data Applianceの監査
注意:
Audit Vault and Database FirewallはOracle Big Data Applianceで使用できなくなりました。監視にはCloudera Navigatorを使用することをお薦めします。3.13 オラクル社カスタマ・サポートに提供する診断情報の収集
CDHの問題のトラブルシューティングを行うために、Oracleサポートのアドバイスが必要な場合は、まずbdadiagユーティリティをcmオプションを指定して使用し、診断情報を収集してください。
診断情報を収集するには、次の手順を実行します。
-
Oracle Big Data Applianceサーバーに
rootとしてログインします。 -
少なくとも
cmオプションを指定してbdadiagを実行します。必要に応じてコマンドに他のオプションを含めることができます。bdadiagの構文の詳細は、『Oracle Big Data Applianceオーナーズ・ガイド』を参照してください。# bdadiag cm
コマンド出力によって、診断ファイルの名前と場所が識別されます。
-
My Oracle Support (
http://support.oracle.com)へ移動します。 -
サービス・リクエスト(SR)を開きます(まだ開いていない場合)。
-
SRに
bz2ファイルをアップロードします。ファイルのサイズが大きすぎる場合は、sftp.oracle.comにアップロードしてください(次の手順を参照)。
診断情報をftp.oracle.comにアップロードするには、次の手順を実行します。
-
SFTPクライアントを開き、
sftp.oracle.comに接続します。ポート2021とリモート・ディレクトリ/support/incoming/targetを指定します(targetは、Oracle Supportにより指定されたフォルダ名です)。 -
Oracle Single Sign-Onのアカウントとパスワードでログインします。
-
診断ファイルを新しいディレクトリにアップロードします。
-
このフル・パスおよびファイル名でSRを更新します。