| Oracle® Big Data Applianceソフトウェア・ユーザーズ・ガイド リリース4 (4.0) E57728-01 |
|
 前 |
 次 |
この章では、Oracle Big Data Applianceにインストールされるソフトウェアおよびサービスについて説明します。次の項について説明します。
Oracle Enterprise Managerプラグインでは、Oracle Exadata Database Machineや他のOracle Databaseインストールに使用するのと同じシステム監視ツールをOracle Big Data Applianceに使用できます。プラグインを使用して、インストールされたソフトウェア・コンポーネントのステータスを表や図式を使用した形式で表示したり、これらのソフトウェア・サービスの起動や停止を行えます。ネットワークおよびラック・コンポーネントの状態を監視することもできます。
Oracle Enterprise Managerを使用すると、同じインフィニバンド・ファブリック上のすべてのOracle Big Data Applianceラックを監視できます。ラック・ハードウェアと論理クラスタのソフトウェア・レイアウトの両方のサマリー・ビューが用意されています。
Oracle Enterprise Manager Webインタフェースを開いてログインし、ターゲット・クラスタを選択すると、次の主要領域へドリルダウンできます。
インフィニバンド・ネットワーク: インフィニバンド・スイッチとポートのネットワーク・トポロジとステータス。図2-1を参照してください。
Hadoopクラスタ: HDFS、MapReduceおよびZooKeeperのソフトウェア・サービス。
Oracle Big Data Applianceラック: サーバー・ホスト、Oracle Integrated Lights Out Manager (Oracle ILOM)サーバー、配電ユニット(PDU)、イーサネット・スイッチなどのハードウェア・ステータス。
図2-1は、クラスタ・ホームページの一部を示しています。
Oracle Enterprise Managerを使用してOracle Big Data Applianceを監視するには、次の手順を実行します。
プラグインをダウンロードしてインストールします。『Oracle Enterprise Manager System Monitoring Plug-inインストレーション・ガイドfor Oracle Big Data Appliance』を参照してください。
管理ユーザーとしてOracle Enterprise Managerにログインします。
「ターゲット」メニューから「ビッグ・データ・アプライアンス」を選択し、ビッグ・データ・ページを表示します。Oracle Enterprise Managerによって検出済のターゲットの全体的なステータスが表示されます。
詳細ページを表示するターゲット・クラスタを選択します。
ターゲット・ナビゲーション・ツリーを展開し、コンポーネントを表示します。すべてのレベルで情報を使用可能です。
ツリーでコンポーネントを選択し、ホーム・ページを表示します。
表示を変更するには、メイン表示領域の左上部にあるドロップダウン・メニューから項目を選択します。
|
関連項目: インストール手順と使用例については、『Oracle Enterprise Manager System Monitoring Plug-inインストレーション・ガイドfor Oracle Big Data Appliance』を参照してください。 |
Enterprise Managerコマンドライン・インタフェース(emcli)はOracle Big Data Applianceに、他のすべてのソフトウェアとともにインストールされます。このインタフェースは、Webインタフェースと同じように機能します。Oracle Management Serverに接続するための資格証明を入力する必要があります。
ヘルプを表示するには、emcli helpと入力してください。
|
関連項目: 『Oracle Enterprise Managerコマンドライン・インタフェース・ガイド』 |
Oracle Big Data ApplianceにインストールされるCloudera Managerは、Cloudera's Distribution including Apache Hadoop (CDH)の操作に役立ちます。Cloudera Managerは、Hadoopクラスタの一部として構成されたすべてのOracle Big Data Applianceサーバーを対象とする単一の管理インタフェースを備えています。
Cloudera Managerを使用すると、次の管理タスクを簡単に行うことができます。
ジョブおよびサービスの監視
サービスの開始および停止
セキュリティ資格証明とKerberos資格証明の管理
ユーザー・アクティビティの監視
システムの状態の監視
パフォーマンス・メトリックの監視
ハードウェアの使用状況の追跡(ディスク、CPU、RAM)
Cloudera Managerは、ResourceManagerノード(node03)上で動作し、ポート7180上で使用できます。
Cloudera Managerを使用するには、次の手順を実行します。
ブラウザを開き、次のようにURLを入力します。
http://bda1node03.example.com:7180
この例で、bda1はアプライアンス名、node03はサーバー名、example.comはドメイン、7180はデフォルトのポート番号(それぞれCloudera Managerで使用)を示します。
Cloudera Managerのユーザー名とパスワードでログインします。設定を変更できるのは、管理者権限を持つユーザーのみです。その他のCloudera Managerユーザーは、Oracle Big Data Applianceのステータスを表示できます。
|
関連項目: Cloudera Manager Monitoring and Diagnostics Guideまたは、Cloudera Managerの「Support」メニューで、「Help」をクリックしてください |
Cloudera Managerでは、画面上部のメニュー・バーから、次に示す任意のページを選択できます。
Home: アクティビティの概要をグラフィカルに表示し、Cloudera Managerによって制御されているすべてのサービスにリンクします。図2-2を参照してください。
Clusters: 複数のクラスタ上のサービスにアクセスします。
Hosts: クラスタのすべてのサーバーの状態、ディスク使用量、負荷、物理メモリー、スワップ領域などの統計情報を監視します。
Diagnostics: イベントおよびログにアクセスします。Cloudera Managerは、システムとサービスに関する履歴情報を収集します。選択したサーバー、サービス、および期間を対象に、特定の句を検索できます。また、ログ・メッセージの最小重大度(TRACE、DEBUG、INFO、WARN、ERRORまたはFATAL)を選択して、検索に含めることもできます。
Audits: 選択した時間範囲の監査履歴ログを表示します。ユーザー名、サービスまたはその他の条件によって結果を絞り込み、CSVファイルとしてログをダウンロードできます。
Charts: Cloudera Managerの時系列データ・ストアから各種のグラフ・タイプ(折れ線グラフ、棒グラフなど)でメトリックを表示できます。
Backup: スナップショット・ポリシーおよびスケジュール済のレプリケーションにアクセスします。
Administration: 「Settings」、「Alerts」、「Users」、「Kerberos」など各種の管理オプションを提供します。
図2-2に、Cloudera Managerのホームページを示します。
Cloudera Manager管理者は、Oracle Big Data Applianceの状態や使用状況を監視するための様々なプロパティの変更、ユーザーの追加、およびKerberosセキュリティの設定を行うことができます。
Cloudera Manager Administrationにアクセスするには、次の手順を実行します。
管理者権限でCloudera Managerにログインします。
「Administration」をクリックし、メニューからタスクを選択します。
Cloudera Managerは次のサービスを管理するインタフェースを備えています。
HDFS
Hive
Hue
Oozie
YARN
ZooKeeper
Cloudera Managerを使用すると、これらのサービスの設定変更、停止および再開を行うことができます。追加のサービスも使用できますが、使用する前に構成が必要です。「未構成のソフトウェア」を参照してください。
|
注意: Linuxサービス・スクリプトやHadoop構成ファイルを手動で編集しても、これらのサービスには何の効果もありません。これらを管理および構成するには、Cloudera Managerを使用する必要があります。 |
ネイティブのHadoopユーティリティを使用することもできます。これらのユーティリティは読取り専用であり、認証を必要としません。
Cloudera Managerでは、これらのユーティリティの正しいURLを簡単に取得できます。「YARN」サービス・ページで、「Web UI」サブメニューを展開します。
リソース・マネージャのインタフェースを使用してMapReduceジョブを監視できます。
MapReduceジョブを監視するには、次の手順を実行します。
ブラウザを開き、次のようにURLを入力します。
http://bda1node03.example.com:8088
この例では、bda1はラックの名前、node03はYARNリソース・マネージャが実行されているサーバーの名前、8088はユーザー・インタフェースのデフォルトのポート番号です。
図2-3に、リソース・マネージャのインタフェースを示します。
クラスタの最初の2つのノードでDFS状態ユーティリティを使用することで、Hadoopファイル・システムの状態を監視できます。
HDFSを監視するには、次の手順を実行します。
ブラウザを開き、次のようにURLを入力します。
http://bda1node01.example.com:50070
この例では、bda1はラックの名前、node01はdfshealthユーティリティが実行されているサーバーの名前、50070はユーザー・インタフェースのデフォルトのポート番号です。
図2-3に、DFS状態ユーティリティのインタフェースを示します。
Hueはブラウザで動作し、複数のアプリケーションに使いやすいインタフェースを提供して、HadoopとHDFSの操作をサポートします。Hueを使用すると、次のタスクを実行できます。
Hiveデータ・ストアの問合せ
Hive表の作成、ロードおよび削除
HDFSファイルおよびディレクトリの操作
MapReduceジョブの作成、発行および監視
MapReduceジョブの監視
Oozieダッシュボードを使用したワークフローの作成、編集および発行
ユーザーおよびグループの管理
Hueは、Oracle Big Data Applianceに自動的にインストールおよび構成されます。HueはResourceManagerノード(node03)のポート8888上で動作します。
Hueを使用するには、次の手順を実行します。
Cloudera Managerにログインし、「Home」ページのhueサービスをクリックします。
hueページで、「Hue Web UI」をクリックします。
ブラウザでHueを直接開けるように、HueのURLをブックマークします。次にURLの例を示します。
http://bda1node03.example.com:8888
Hue資格証明を使用してログインします。
Oracle Big Data Applianceは、初期設定では特定のHueユーザー・アカウントを使用するよう構成されていません。Hueに最初に接続するユーザーは、任意のユーザー名とパスワードでログインでき、自動的に管理者になります。このユーザーは、他のユーザーと管理者アカウントを作成できます。
図2-5に、Hive Query Editorを示します。
次の各項では、Oracle Big Data Applianceにインストールされるソフトウェアについて説明します。一部のコンポーネントは、Oracle Database 11.2.0.2以降のリリースで動作します。
この項の内容は次のとおりです。
これらのソフトウェア・コンポーネントは、クラスタのすべてのサーバーにインストールされます。Oracle Linux、必須ドライバ、ファームウェアおよびハードウェア検証ユーティリティは工場出荷時にインストール済です。その他のソフトウェアは、すべてサイトにインストールします。オプションのソフトウェア・コンポーネントは、インストールで構成されない場合があります。
|
注意: Oracle Big Data Applianceに追加のソフトウェアをインストールする必要はありません。これを行うと、保証やサポートの対象外となる可能性があります。詳細は、『Oracle Big Data Applianceオーナーズ・ガイド』を参照してください。 |
ベースとなるイメージ・ソフトウェア:
Oracle Unbreakable Enterprise Kernelバージョン2 (UEK2)を搭載したOracle Linux 6.4 (アップグレードは5.8のまま)
Java HotSpot Virtual Machine 7バージョン25 (JDK 7u25)
Oracle R Distribution 3.0.1-2
MySQL Database 5.5.35 Advanced Edition
Puppet、ファームウェア、Oracle Big Data Applianceユーティリティ
Oracleインフィニバンド・ソフトウェア
Mammothインストール:
Cloudera's Distribution including Apache Hadoop Release 5 (5.1.0)には次のものが含まれます。
Apache Hive 0.12
Apache HBase
Apache Spark
Cloudera Search 1.2.0
Cloudera Manager Release 5 (5.1.1) including Cloudera Navigator
Oracle Big Data SQL (オプション)
Oracle NoSQL Database Community EditionまたはEnterprise Edition 12c Release 1 Version 3.0.5 (オプション)
Oracle Big Data Connectors 4.0 (オプション):
|
関連項目: Mammothユーティリティの詳細は、『Oracle Big Data Applianceオーナーズ・ガイド』を参照してください。 |
図2-6は、主要コンポーネント間の関係を示しています。
ご使用のOracle Big Data Applianceライセンスには、Cloudera Enterprise Data Hub Editionのすべてのコンポーネントが含まれています。すべてのCDHコンポーネントは、Mammothユーティリティによって自動的にインストールされます。これらは、Cloudera Webサイトからはダウンロードしないでください。
|
関連項目: CDHコンポーネントの完全なリストについては、次を参照してください。
|
ただし、次のサービスは、使用前にCloudera Managerを使用して追加する必要があります。
サービスを追加するには、次の手順を実行します。
adminユーザーとしてCloudera Managerにログインします。
「Home」ページで、左側のパネルのクラスタ・メニューを展開し、「Add a Service」を選択して「Add Service」ウィザードを開きます。最初のページには、追加できるサービスがリストされます。
ウィザードのステップに従います。
各クラスタの最初のサーバー上のRPMファイルは、/opt/oracle/BDAMammoth/bdarepo/RPMS/noarchにあります。
|
関連項目: 構成の手順の詳細は、次のサイトで『CDH5 Installation and Configuration Guide』を参照してください |
リソース・プールの合計の割合として、リソースをHDFS、YARN、Oracle Big Data SQL、Hiveなどの各サービスに割り当てることができます。Cloudera Managerでは、これらの割合に基づいて推奨されるリソース管理設定が自動的に計算されます。あるサービスに対する高負荷が他のサービスに与える影響が制限されるように、静的サービス・プールはクラスタ上のサービスを切り離します。
サービス間にリソースを割り当てるには、次の手順を実行します。
adminとしてCloudera Managerにログインします。
ページの上部の「Clusters」メニューを開き、「Resource Management」の下の「Static Service Pools」を選択します。
「Configuration」を選択します。
ウィザードのステップに従うか、または「Change Settings Directly」をクリックして現在の設定を変更します。
すべてのサービスはCDHクラスタ内の全ノード上にインストールされますが、個々のサービスは指定されたノードでのみ実行されます。サービスの場所は、クラスタの構成によって多少異なります。
この項では、デフォルトのYARN構成のサービスについて説明します。
この項の内容は次のとおりです。
表2-1は、シングル・ラック内に構成されたCDHクラスタ内のサービスを示したものです(スタータ・ラックおよび6ノードのクラスタを含む)。Node01はクラスタ内の最初のサーバー(サーバー1、7または10)で、nodennはクラスタ内の最後のサーバー(サーバー6、9、12または18)です。
表2-1 シングル・ラック内にある1つ以上のCDHクラスタのサービス・ロケーション
| node01 | node02 | node03 | Node04 | Node05～nn |
|---|---|---|---|---|
|
バランサ |
Cloudera Manager Server |
|||
|
Cloudera Manager Agent |
Cloudera Manager Agent |
Cloudera Manager Agent |
Cloudera Manager Agent |
Cloudera Manager Agent |
|
DataNode |
DataNode |
DataNode |
DataNode |
DataNode |
|
Failover Controller |
Failover Controller |
JobHistory |
Hive、Hue、Oozie、Solr |
|
|
JournalNode |
JournalNode |
JournalNode |
||
|
MySQL Backup |
MySQL Primary |
|||
|
NameNode |
NameNode |
|||
|
NodeManager脚注 1 |
NodeManager脚注 1 |
NodeManager |
NodeManager |
NodeManager |
|
Oracle Data Integratorエージェント |
||||
|
Puppet |
Puppet |
Puppet |
Puppet |
Puppet |
|
Puppet Master |
ResourceManager |
ResourceManager |
||
|
ZooKeeper |
ZooKeeper |
ZooKeeper |
脚注 1 スタータ・ラックおよび6ノード・クラスタのみ、割当て済リソースを減らした状態
複数のラックが単一のCDHクラスタとして構成される場合、いくつかの重要なサービスが第2ラックにインストールされます。第2ラックには少なくとも2つのノードが必要です。
表2-2は、マルチラック・クラスタの最初のラックで実行されるサービスの場所を示したものです。
表2-2 マルチラックCDHクラスタの最初のラックでのサービス・ロケーション
| node01 | node02 | node03 | Node04 | Node05～nn脚注 1 |
|---|---|---|---|---|
|
Cloudera Manager Agent |
Cloudera Manager Agent |
Cloudera Manager Agent |
Cloudera Manager Agent |
Cloudera Manager Agent |
|
Cloudera Manager Server |
||||
|
DataNode |
DataNode |
DataNode |
DataNode |
DataNode |
|
Failover Controller |
||||
|
JournalNode |
JournalNode |
|||
|
NameNode |
MySQL Primary |
|||
|
NodeManager |
NodeManager |
NodeManager |
NodeManager |
NodeManager |
|
Puppet |
Puppet |
Puppet |
Puppet |
Puppet |
|
Puppet Master |
ResourceManager |
|||
|
ZooKeeper |
ZooKeeper |
脚注 1 nnには追加ラック内のサーバーが含まれます。
表2-3は、マルチラック・クラスタの第2ラックで実行されるサービス・ロケーションを示したものです。
表2-3 マルチラックCDHクラスタの第2ラックでのサービス・ロケーション
| node01 | node02 | node03 | Node04 | Node05～nn |
|---|---|---|---|---|
|
バランサ |
||||
|
Cloudera Manager Agent |
Cloudera Manager Agent |
Cloudera Manager Agent |
Cloudera Manager Agent |
Cloudera Manager Agent |
|
DataNode |
DataNode |
DataNode |
DataNode |
DataNode |
|
Failover Controller |
||||
|
JournalNode |
Hive、Hue、Oozie、Solr |
|||
|
MySQL Backup |
||||
|
NameNode |
||||
|
NodeManager脚注 1 |
NodeManager脚注 1 |
NodeManager |
NodeManager |
NodeManager |
|
Oracle Data Integratorエージェント |
||||
|
Puppet |
Puppet |
Puppet |
Puppet |
Puppet |
|
Puppet Master |
ResourceManager |
|||
|
ZooKeeper |
脚注 1 スタータ・ラックおよび6ノード・クラスタのみ、割当て済リソースを減らした状態
|
注意: 1つのラックから2つのラックにクラスタを展開する場合、Mammothは最初のラックのノード2および4から重要なサービスをすべて、第2ラックのノード1および2に移動します。最初のラックのノード2は、非クリティカル・ノードになります。 |
Yet Another Resource Negotiator (YARN)は、Oracle Big Data Appliance 3.0から始まるMapReduceのデフォルト・バージョンです。本番システムにはYARNを使用することをお薦めします。MapReduce 1 (MRv1)は下位互換性のためにサポートされていますが、手動でインストールする必要があります。同じクラスタ上で両方のバージョンのMapReduce (YARNとMRv1)を実行しないでください。
MapReduce 1を使用して開発されたMapReduceアプリケーションをYARNで実行するには、再コンパイルが必要な場合があります。
ResourceManagerは、すべてのリソース管理タスクを実行します。MRAppMasterはジョブ管理タスクを実行します。各ジョブには独自のMRAppMasterがあります。NodeManagerには、マップ・タスク、リデュース・タスクまたはMRAppMasterを実行できるコンテナがあります。NodeManagerは使用可能なメモリーを使用してコンテナを動的に割り当てることができます。このアーキテクチャによりスケーラビリティが向上し、MRv1よりもクラスタを活用できます。
YARNはSparkおよびImpalaのリソースも管理します。
MRv1はMapReduceジョブを排他的に管理します。JobTrackerはResourceManagerとMRAppMasterの機能を結合します。TaskTrackerはNodeManagerの機能を実行します。
|
関連項目: 次のサイトで「Running Existing Applications on Hadoop 2 YARN」を参照してください。
|
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 2.0以降のリリースでは、バックアップ用の外部NFSフィルタをサポートしておらず、NameNodeのフェデレーションを使用しません。 |
図2-7は、NameNodeの自動フェイルオーバーをサポートしているプロセス間の関係を示しています。
図2-7 Oracle Big Data ApplianceでのNameNodeの自動フェイルオーバー
ResourceManagerは、クラスタ内のアプリケーション・タスクおよびアプリケーション・マスターにリソースを割り当てます。NameNodeと同様、ResourceManagerはクラスタの重要な障害ポイントです。すべてのResourceManagerで障害が起きると、すべてのジョブが実行を停止します。Oracle Big Data Appliance 3.0は、この脆弱性を軽減するためにCloudera 5でResourceManager High Availabilityをサポートしています。
CDHは、node03とnode04上の冗長なResourceManagerサービスを管理します。それらのサービスの1つがアクティブ・モードになり、その他のサービスはホット・スタンバイ・モードになります。アクティブ・サービスに障害が発生すると、そのアクティブResourceManagerのロールは自動的にスタンバイ・サービスにフェイルオーバーされます。フェイルオーバー・コントローラは不要です。
図2-7は、ResourceManagerの自動フェイルオーバーをサポートしているプロセス間の関係を示しています。
図2-8 Oracle Big Data ApplianceでのResourceManagerの自動フェイルオーバー
表2-4に示すように、NodeManagerサービスには固定量のメモリーおよびCPUコア電圧(Vcore)が割り当てられます。
表2-4 NodeManagerのリソース割当て
| アプライアンス・モデル | メモリー | VCore |
|---|---|---|
|
Oracle Big Data Appliance X4-2 |
40GB |
32V |
|
Oracle Big Data Appliance X3-2 |
40GB |
32V |
|
Oracle Big Data Appliance (Sun Fire X4270 M2ベース・パック) |
30GB |
24V |
クラスタ内の各ノードには、同時実行を許可されるマップ・タスクとリデュース・タスクの最大数があります。表2-5は、Oracle Big Data Appliance X4-2およびX3-2でのMapReduceサービスのデフォルトのリソース構成を示したものです。
表2-5 Oracle Big Data Appliance X3-2でのマップおよびリデュース・タスクの最大数
| ノード | 6ノード・クラスタ | より大規模なクラスタ脚注 1 |
|---|---|---|
|
Node01とNode02 |
14マップ 8リデュース |
なし(NodeManagerなし) |
|
Node03とNode04 |
10マップ 6リデュース |
10マップ 6リデュース |
|
Node05～Nodenn |
20マップ 13リデュース |
20マップ 13リデュース |
脚注 1 9ノード以上
表2-6は、Oracle Big Data Appliance Sun Fire X4270 M2ベース・ラックでのMapReduceサービスのデフォルトのリソース構成を示したものです。
表2-6 Sun Fire X4270 M2ベース・ラックでのマップおよびリデュース・タスクの最大数
| ノード | 6ノード・クラスタ | より大規模なクラスタ脚注 1 |
|---|---|---|
|
Node01とNode02 |
10マップ 6リデュース |
なし |
|
Node03とNode04 |
7マップ 4リデュース |
7マップ 4リデュース |
|
Node05～Nodenn |
15マップ 10リデュース |
15マップ 10リデュース |
脚注 1 9ノード以上
サーバー障害の影響は、CDHクラスタ内におけるサーバーの機能によって異なります。Oracle Big Data Applianceサーバーは、コモディティ・ハードウェアよりも堅牢なため、ハードウェア障害が発生することはほとんどありません。この項では、プライマリ・ラックの様々なサーバー上で実行される重要性の高いサービスに焦点を当てています。詳細なリストは、「シングルラック・クラスタ上でサービスが実行される場所」を参照してください。
各サーバーには12基のディスクが搭載されています。重要なオペレーティング・システムはディスク1および2に格納されます。
表2-7に、ディスク・パーティションの内容を示します。
クリティカル・ノードは、クラスタが正常に動作し、すべてのサービスをユーザーに提供するために必要です。これとは対照的に、非クリティカル・ノードに障害が発生しても、クラスタはサービスを失うことなく動作し続けます。
シングルラック・クラスタでは、重要なサービスはクラスタの最初の4つのノードに初期インストールされます。残りのノード(node05から最大でnode18まで)は重要性の低いサービスのみを実行します。クリティカル・ノードのいずれかでハードウェア障害が発生した場合は、別の非クリティカル・サーバーにサービスを移行できます。たとえば、node02に障害が発生した場合、重要なサービスをnode05に移行できます。表2-1は、シングル・ラック上に構成されたクラスタのサービスの初期ロケーションを示したものです。
マルチラック・クラスタでは、一部の重要なサービスが第2ラックの第1サーバーで実行されます。「シングルラック・クラスタ上でサービスが実行される場所」を参照してください。
一部のサービスには高可用性と自動フェイルオーバーが含まれています。単一障害点を含むサービスもあります。次のリストに、重要なサービスを示します。
NameNodes: 高可用性と自動フェイルオーバー
ResourceManagers: 高可用性と自動フェイルオーバー
MySQL Database: プライマリ・データベースおよびバックアップ・データベースは、バックアップ・データベースに対するプライマリ・データベースのレプリケーションで構成されます。自動フェイルオーバーはありません。プライマリ・データベースに障害が発生すると、クラスタの機能は失われますが、データは失われません。
Cloudera Manager: Cloudera Managerサーバーは1つのノードで実行されます。障害が発生すると、Cloudera Manager機能は使用できません。
Oozieサーバー、Hiveサーバー、HueサーバーおよびOracle Data Integratorエージェント: これらのサービスには冗長性はありません。ノードに障害が発生すると、サービスは使用できません。
表2-8に、重要なサービスが実行される場所を示します。これらの4つのノードの詳細は、この後のトピックで説明します。
表2-8 シングル・ラックでの重要なサービスの場所
| ノード名 | 重要な機能 |
|---|---|
|
第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つの重要なノードが作成されます。「シングルラック・クラスタ上でサービスが実行される場所」を参照してください。
マルチラック・クラスタでは、第2NameNodeノードと第2ResourceManagerノードは第2ラックの最初の2つのノードに移動されます。「マルチラック・クラスタ上でサービスが実行される場所」を参照してください。
第1NameNodeに障害が発生するか、オフライン(再起動など)になると、第2NameNodeが自動的に引き継いで、クラスタの正常なアクティビティを維持します。
または、第2NameNodeがすでにアクティブな場合は、バックアップなしで動作し続けます。NameNodeが1つのみの場合、クラスタは障害に対して脆弱です。クラスタが、自動フェイルオーバーに必要な冗長性を失うためです。
Puppetマスターもこのノードで実行されます。MammothユーティリティではPuppetを使用するので、たとえばラック内の別の場所にあるディスク・ドライブを交換する必要がある場合、ソフトウェアのインストールまたは再インストールはできません。
第2NameNodeに障害が発生すると、NameNodeの機能は第1NameNode (node01)にフェイルオーバーされるか、そのままバックアップなしで動作し続けます。ただし、第1NameNodeにも障害が発生すると、クラスタは自動フェイルオーバーに必要な冗長性を失っています。
MySQLバックアップ・データベースもこのノードで実行されます。MySQL Databaseは動作を継続しますが、マスター・データベースのバックアップはありません。
第1ResourceManagerに障害が発生するか、(再起動などによって)オフラインになると、第2ResourceManagerが自動的に機能を引き継ぎ、MapReduceタスクをクラスタの特定のノードへと分配します。
または、第2ResourceManagerがすでにアクティブな場合は、バックアップなしで動作し続けます。ResourceManagerが1つのみの場合、クラスタは障害に対して脆弱です。クラスタが、自動フェイルオーバーに必要な冗長性を失うためです。
次のサービスも影響を受けます。
Cloudera Manager: このツールは、CDHクラスタ全体の一元管理機能を提供します。このツールがない場合は、「Hadoop監視ユーティリティの使用方法」で説明したユーティリティを使用すれば、引き続きアクティビティを監視できます。
MySQL Database: Cloudera Manager、Oracle Data Integrator、HiveおよびOozieはMySQLデータベースを使用しています。データは自動的にレプリケートされますが、マスター・データベース・サーバーが停止していると、それにはアクセスできません。
第2ResourceManagerノードに障害が発生すると、ResourceManagerの機能は第1ResourceManagerにフェイルオーバーされるか、そのままバックアップなしで動作し続けます。ただし、第1ResourceManagerにも障害が発生すると、クラスタは自動フェイルオーバーに必要な冗長性を失っています。
次のサービスも影響を受けます。
Oracle Data Integrator: このサービスは、Oracle Data Integrator Application Adapter for Hadoopをサポートしています。ResourceManagerノードが停止している場合、このコネクタは使用できません。
Hive: Hiveは、HDFSに格納されているデータへのSQLライクなインタフェースを備えています。Oracle Big Data SQLおよびOracle Big Data Connectorsの大部分はHive表にアクセスできますが、このノードに障害が発生した場合、この表は使用できません。
Oozie: このワークフローおよび調整サービスはResourceManagerノードで実行され、このノードがダウンしているときには使用できません。
サーバーに障害が発生した場合、できるかぎり短い中断時間で、クラスタのサービスを保守する手順を実行する必要があります。次の手順で説明するように、bdacliユーティリティを使用して、障害が発生しているサーバーを簡単に管理できます。管理手順の1つはデコミッショニングと呼ばれます。デコミッショニングは、すべてのサービスのすべてのロールを停止するため、データが失われることはありません。Cloudera Managerでは、ノードを終了する前にデコミッションする必要があります。
非クリティカル・ノードに障害が発生しても、サービスが失われることはありません。ただし、クリティカル・ノードに障害が発生した場合、「ソフトウェアの可用性に与えるハードウェアの影響」で説明するように、単一障害点を持つサービスは使用できません。次の選択肢のどちらかに決める必要があります。
修理が行われるのを待機し、修理が完了するまでサービスが失われた状態が続きます。
重要なサービスを別のノードに移動します。これを選択すると、一部のクライアントを新しいノードのアドレスで再構成する必要がある場合があります。たとえば、第2ResourceManagerノード(通常はnode03)で障害が発生した場合、ユーザーはブラウザを新しいノードにリダイレクトしてCloudera Managerにアクセスする必要があります。
サービスの喪失とクライアントを再構成する不便さとを比較検討する必要があります。
前提条件
障害が発生しているサーバーを管理する前に、次のことを実行します。
サービスまたはサーバーを再起動してみます。
障害が発生しているノードがクリティカルか非クリティカルかを判断します。
障害が発生しているノードが、Mammothがインストールされているノードの場合:
障害が発生しているノードと同じラックで非クリティカル・ノードを選択します。
Mammothバンドルをそのノードにアップロードしてインストールします。インストールの完了後、このノードからすべてのMammoth操作を実行する必要があります。
詳細は、『Oracle Big Data Applianceオーナーズ・ガイド』を参照してください。
障害が発生しているクリティカル・ノードを管理するためのこの項の手順に従います。
サービスが以前に移行されていないかぎり、Mammothはクラスタの第1ノードにインストールされます。
障害が発生しているクリティカル・ノードを管理するには、次の手順を実行します。
Mammothがインストールされているノードにrootとしてログインします。
サービスを非クリティカル・ノードに移行します。node_nameを、障害が発生しているノードの名前(bda1node02など)に置換します。
bdacli admin_cluster migrate node_name
コマンドが完了すると、node_nameがデコミッションされ、以前の非クリティカル・ノードでサービスが実行されます。
ユーザーが必要に応じてクライアントを新しいクリティカル・ノードにリダイレクトできるように、変更をユーザー・コミュニティに通知します。
障害が発生したサーバーを修理または交換します。
rootとしてMammothノードから、修理または交換したサーバーを非クリティカル・ノードとして再プロビジョニングします。node_nameには、移行されたノードと同じ名前(bda1node02など)を使用します。
bdacli admin_cluster reprovision node_name
障害が発生したノードがHBaseやImpalaのようなサービス(Mammothによってインストールされているが、構成されていない状態)をサポートしていた場合、Cloudera Managerを使用してそれらを新しいノードで再構成します。
障害が発生している非クリティカル・ノードを管理するには、次の手順を実行します。
Mammothがインストールされているノード(通常はnode01)にrootとしてログインします。
障害が発生しているノードをデコミッションします。node_nameを、障害が発生しているノードの名前(bda1node07など)に置換します。
bdacli admin_cluster decommission node_name
障害が発生したサーバーを修理または交換します。
rootとしてMammothノードから、修理または交換したサーバーを再コミッションします。node_nameには、デコミッションされたノードと同じ名前(bda1node07など)を使用します。
bdacli admin_cluster recommission node_name
|
関連項目: bdacliの構文の詳細は、『Oracle Big Data Applianceオーナーズ・ガイド』を参照してください。 |
この項では、Oracle Big Data Applianceを正常に停止して再起動する方法について説明します。
rootアクセス権が必要です。dcliユーティリティを使用できるように、クラスタにパスワードなしSSHが設定されている必要があります。
パスワードなしSSHが設定されていることを確認するには、次の手順を実行します。
クラスタの第1ノードにrootとしてログインします。
dcliコマンドを使用して、コマンドが動作していることを確認します。このコマンドは、クラスタ内のすべてのノードのIPアドレスおよびホスト名を返します。
# dcli -C hostname
192.0.2.1: bda1node01.example.com
192.0.2.2: bda1node02.example.com
.
.
.
これらの結果が得られない場合は、クラスタでdcliを設定します。
# setup-root-ssh -C
|
関連項目: これらのコマンドの詳細は、『Oracle Big Data Applianceオーナーズ・ガイド』を参照してください。 |
次の手順に従って、すべてのOracle Big Data Applianceソフトウェアおよびハードウェア・コンポーネントを停止します。
|
注意: システムが停止すると、次のサービスは自動的に停止します。処理を実行する必要はありません。
|
Cloudera Managerを使用して、Cloudera Managerが管理するサービス(flume、hbase、hdfs、hive、hue、mapreduce、oozieおよびzookeeper)を停止します。
adminユーザーとしてCloudera Managerにログインします。
詳細は、「Cloudera Managerを使用した操作の管理」を参照してください。
開始ページの「Status」ペインで、クラスタのメニューを展開し、「Stop」をクリックした後、確認するように要求されたら「Stop」を再びクリックします。図2-9を参照してください。
このページに移動するには、「Home」タブをクリックし、「Status」サブタブをクリックします。
「Command Details」ページで、すべてのプロセスが停止したら「Close」をクリックします。
Cloudera Management Servicesの同じペインで、mgmtサービスのメニューを展開し、「Stop」をクリックします。
Cloudera Managerからログアウトします。
次の手順に従って、Cloudera Manager Serverを停止します。
Cloudera Managerが実行されているノード(最初はnode03)にrootとしてログインします。
|
注意: 残りのタスクでは、サーバーにrootとしてログインしているとみなされます。dcliコマンドを使用すると、任意のサーバーからコマンドを入力できます。この例では、クラスタ内の任意のノードからnode03でpwdコマンドを実行します。
# dcli -c node03 pwd |
Cloudera Managerサーバーを停止します。
# service cloudera-scm-server stop Stopping cloudera-scm-server: [ OK ]
サーバーが停止したことを確認します。
# service cloudera-scm-server status
cloudera-scm-server is stopped
Cloudera Managerを停止した後、Webコンソールを使用してアクセスすることはできません。
クラスタにOracle Data Integrator Application Adapter for Hadoopがインストールされている場合は、エージェントを停止します。
Oracle Data Integratorサービスのステータスを確認します。
# dcli -C service odi-agent status
Oracle Data Integratorエージェントが実行中の場合は、停止します。
# dcli -C service odi-agent stop
Oracle Data Integratorサービスの実行が停止したことを確認します。
# dcli -C service odi-agent status
すべてのノードがnode03でNFSディレクトリを共有しており、追加のディレクトリが存在する場合もあります。NFSディレクトリ(/opt/exportdir)を含むサーバーを使用できない場合、停止しようとすると他のサーバーがハングします。したがって、まずNFSディレクトリをディスマウントする必要があります。
マウントされているNFSディレクトリを探します。
# dcli -C mount | grep shareddir
192.0.2.1: bda1node03.example.com:/opt/exportdir on /opt/shareddir type nfs (rw,tcp,soft,intr,timeo=10,retrans=10,addr=192.0.2.3)
192.0.2.2: bda1node03.example.com:/opt/exportdir on /opt/shareddir type nfs (rw,tcp,soft,intr,timeo=10,retrans=10,addr=192.0.2.3)
192.0.2.3: /opt/exportdir on /opt/shareddir type none (rw,bind)
.
.
.
サンプル出力は、node03 (192.0.2.3)上の共有ディレクトリを示します。
共有ディレクトリをディスマウントします。
# dcli -C umount /opt/shareddir
カスタムNFSディレクトリをディスマウントします。
Linuxのshutdown -hコマンドは、個別のサーバーの電源を切断します。dcli -gコマンドを使用すると、複数のサーバーを停止できます。
クラスタ内の他のサーバー(つまり、ログインしているサーバーを除く)の名前またはIPアドレスをリストしたファイルを作成します。
他のサーバーを停止します。
# dcli -g filename shutdown -h now
filenameには、手順1で作成したファイルの名前を入力します。
ログインしているサーバーを停止します。
# shutdown -h now
ネットワーク・スイッチを停止するには、データ・センターのPDUまたはブレーカをオフにします。スイッチがオフになるのは、電源を切断した場合のみです。
ネットワーク・スイッチには電源ボタンがありません。停止するのは、電源を切断した場合のみです。
スイッチを停止するには、2つのPDUのすべてのブレーカをオフにします。
次の手順に従って、ハードウェアの電源を投入し、Oracle Big Data Appliance上のすべてのサービスを開始します。
両方のPDUの12個すべてのブレーカのスイッチを入れます。
Oracle ILOMおよびLinuxオペレーティング・システムがサーバーで起動するには4から5分かかります。
パスワードベースのオンディスク暗号化が有効になっている場合は、ログインしてそれらのサーバーのHadoopディレクトリをマウントします。
$ mount-hadoop-dirs Enter password to mount Hadoop directories: password
サーバーが自動的に起動しない場合は、サーバーの前面にある電源ボタンを押してローカルで起動するか、またはOracle ILOMを使用してリモートで起動できます。Oracle ILOMには、コマンドライン・インタフェース(CLI)やWebコンソールなど、複数のインタフェースがあります。必要なインタフェースを使用します。
たとえば、rootとしてWebインタフェースにログインし、「Remote Power Control」ページからサーバーを起動できます。Oracle ILOMのURLはホストのものと同じですが、通常は-cまたは-ilom拡張子が付いている点が異なります。このURLはbda1node4のOracle ILOMに接続します。
http://bda1node04-ilom.example.com
Cloudera Managerが制御するすべてのHDFSサービスを開始するには、Cloudera Managerを使用します。
Cloudera Managerが実行されているノード(最初はnode03)にrootとしてログインします。
|
注意: 残りのタスクでは、サーバーにrootとしてログインしているとみなされます。dcliコマンドを使用すると、任意のサーバーからコマンドを入力できます。この例では、クラスタ内の任意のノードからnode03でpwdコマンドを実行します。
# dcli -c node03 pwd |
Cloudera Managerがnode03で自動的に起動したことを確認します。
# service cloudera-scm-server status cloudera-scm-server (pid 11399) is running...
実行されていない場合は、起動します。
# service cloudera-scm-server start
adminユーザーとしてCloudera Managerにログインします。
詳細は、「Cloudera Managerを使用した操作の管理」を参照してください。
開始ページの「Status」ペインで、クラスタのメニューを展開し、「Start」をクリックした後、確認するように要求されたら「Start」を再びクリックします。図2-9を参照してください。
このページに移動するには、「Home」タブをクリックし、「Status」サブタブをクリックします。
「Command Details」ページで、すべてのプロセスが開始されたら「Close」をクリックします。
Cloudera Management Servicesの同じペインで、mgmtサービスのメニューを展開し、「Start」をクリックします。
Cloudera Managerからログアウトします(オプション)。
このクラスタでOracle Data Integrator Application Adapter for Hadoopが使用されている場合は、エージェントを起動します。
エージェントのステータスを確認します。
# /opt/oracle/odiagent/agent_standalone/oracledi/agent/bin/startcmd.sh OdiPingAgent [-AGENT_NAME=agent_name]
エージェントを起動します。
# /opt/oracle/odiagent/agent_standalone/oracledi/agent/bin/agent.sh [-NAME=agent_name] [-PORT=port_number]
Oracle Big Data SQLは、アドオン・サービスとしてCloudera Managerに登録されます。Cloudera Managerを使用すると、CDHサービスと同じ方法でOracle Big Data SQLサービスまたは個別のロール・インスタンスを起動、停止および再起動できます。
Cloudera ManagerはOracle Big Data SQLサービスの状態を監視し、サービスの停止をレポートして、サービスが正常に機能していない場合はアラートを送信します。
Oracle Big Data SQLはOracle Big Data Appliance上のオプションのサービスです。ソフトウェアの初期インストール時またはアップグレード時に他のクライアントとともにインストールすることもできます。インストールされているかどうかを判断するには、Cloudera Managerを使用します。個別のライセンスが必要です。Oracle Big Data SQLはOracle Big Data Applianceのライセンスには含まれていません。
Cloudera Managerを使用して、Oracle Big Data Appliance上のCDHクラスタからOracle Big Data SQLサービスを追加または削除することはできません。かわりに、Mammothがインストールされているサーバー(通常はクラスタの第1ノード)にログインし、bdacliユーティリティで次のコマンドを使用します。
Oracle Big Data SQLを有効化するには、次の手順を実行します。
bdacli enable big_data_sql
Oracle Big Data SQLを無効化するには、次の手順を実行します。
bdacli disable big_data_sql
|
関連項目: 『Oracle Big Data Applianceオーナーズ・ガイド』 |
Linuxカーネルのコントロール・グループ(Cgroup)のプロパティ値を変更すると、Oracle Big Data SQL用にリソースを予約できます。
リソース管理の構成設定を変更するには、次の手順を実行します。
adminとしてCloudera Managerにログインします。
「Home」ページで、サービスのリストからbigdatasqlをクリックします。
bigdatasqlページで、「Configuration」をクリックします。
「Category」で、「BDS Server Default Group」を展開し、「Resource Management」をクリックします。
必要に応じて、次のプロパティの値を変更します。
Cgroup CPU Shares
Cgroup I/O Weight
Cgroup Memory Soft Limit
Cgroup Memory Hard Limit
ガイドラインのページの「Description」列を確認します。
「Save Changes」をクリックします。
「Actions」メニューから、「Restart」をクリックします。
図2-10に、bigdatasqlサービスの構成ページを示します。
Oracle Big Data Applianceは、デフォルトではMapReduceのYet Another Resource Negotiator (YARN)実装を使用します。従来のMapReduce (MRv1)を使用することもできます。同じクラスタ内で両方の実装を使用することはできません。MapReduceとYARNサービスのいずれかをアクティブ化できます。
クラスタをMRv1に切り替えるには、次の手順を実行します。
adminユーザーとしてCloudera Managerにログインします。
YARNサービスを停止します。
「Home」ページの「Status」タブのサービスのリストでYARNを探します。
「YARN」メニューを展開し、「Stop」をクリックします。
「cluster」メニューで、「Add a Service」をクリックして「Add Service」ウィザードを開始します。
追加するサービスのタイプとして「MapReduce」を選択します。
依存関係(デフォルト)としてhdfs/zookeeperを選択します。
ロール割当てをカスタマイズします。
JobTracker: フィールドをクリックすると、クラスタ内のノードのリストが表示されます。第3ノードを選択します。
TaskTracker: 6ノード・クラスタの場合は、すべてのノードのTaskTrackerを保持します(デフォルト)。より大きいクラスタの場合は、最初の2つのノードからTaskTrackerを削除します。
「Review Changes」ページで、パラメータ値を変更します。
TaskTracker Local Data Directory List: デフォルト・グループおよびグループ1を"/u12/hadoop/mapred".."/u01/hadoop/mapred"に変更します。
JobTracker Local Data Directory List: デフォルト・グループを"/u12/hadoop/mapred".."/u01/hadoop/mapred"に変更します。
それ以上の変更は加えずにウィザードの手順を完了します。「Finish」をクリックし、構成を保存して終了します。
Hiveサービス構成を更新します。
「Home」ページの「Status」タブで、hiveをクリックしてhiveページを表示します。
「Configuration」サブメニューを展開し、「View and Edit」をクリックします。
MapReduce Serviceプロパティの値としてmapreduceを選択します。
「Save Changes」をクリックします。
手順4を繰り返して、mapreduceを使用するようにOozieサービス構成を更新します。
「Home」ページの「Status」タブで、hiveおよびoozieメニューを展開し、「Restart」を選択します。
オプション: yarnサービス・メニューを展開し、「Delete」を選択します。
yarnサービスを保持する場合は、クラスタを再起動するたびに、「Memory overcommit validation」という警告が表示され、yarnサービスを手動で停止する必要があります。
MapReduceサービス構成を更新します。
「Home」ページの「Status」タブで、mapreduceをクリックしてmapreduceページを表示します。
「Configuration」サブメニューを展開し、「View and Edit」をクリックします。
「Category」で、「TaskTracker Default Group」を展開し、「Resource Management」をクリックします。
次のプロパティを設定します。
Java Heap Size of TaskTracker in Bytes: デフォルト値(1 GiB)にリセットします。
Maximum Number of Simultaneous Map Tasks: 15 (Sun Fire X4270 M2ラック)または20 (他のすべてのラック)に設定します。
Maximum Number of Simultaneous Reduce Tasks: 10 (Sun Fire X4270 M2ラック)または13 (他のすべてのラック)に設定します。
「Save Changes」をクリックします。
ノード3および4 (6ノード・クラスタの場合はノード1および2)のオーバーライドを追加します。「マップとリデュースのリソース構成」を参照してください。
mapreduce1サービスをクリックしてmapreduceページを表示します。
「Actions」メニューを展開し、「Enable High Availability」を選択して「Enable JobTracker High Availability」ウィザードを開始します。
「Assign Roles」ページで、Standby JobTrackerの第4ノード(node04)を選択します。
それ以上の変更は加えずにウィザードの手順を完了します。「Finish」をクリックし、構成を保存して終了します。
クラスタ内のすべてのサービスが正常に機能している(構成の問題がない)ことを確認します。
MRv1クラスタのPerfect Balanceを再構成します。
rootとして、クラスタのノードにログインします。
クラスタのすべてのノード上でPerfect Balanceを構成します。
$ dcli –C /opt/oracle/orabalancer-[version]/bin/configure.sh
dcliコマンドについては、『Oracle Big Data Applianceオーナーズ・ガイド』を参照してください。
Oracle Big Data Applianceではソフトウェアやデータの不正利用を防ぐための予防策を取ることができます。
Oracle Big Data Applianceにインストールされるオープンソース・パッケージごとに、1つ以上のユーザーおよびグループが作成されます。このようなユーザーのほとんどは、ログイン権限、シェル、またはホーム・ディレクトリを持っていません。これらはデーモンによって使用され、各ユーザー向けのインタフェースとしては設計されていません。たとえば、Hadoopはhdfsユーザーとして、MapReduceはmapredとして、Hiveはhiveとしてそれぞれ動作します。
Oracle Big Data Applianceソフトウェアのインストール直後にHadoopおよびHiveジョブを実行するには、oracle IDを使用できます。このユーザー・アカウントは、ログイン権限、シェル、およびホーム・ディレクトリを保持しています。
Oracle NoSQL DatabaseおよびOracle Data Integratorはoracleユーザーとして実行します。プライマリ・グループはoinstallです。
|
注意: インストール時に作成されたユーザーは、ソフトウェアの操作に必要なため、削除、再作成および変更はしないでください。 |
表2-9に、Oracle Big Data Applianceソフトウェアのインストール時に自動的に作成され、CDHコンポーネントおよびその他のソフトウェア・パッケージによって使用されるオペレーティング・システム・ユーザーおよびグループを示します。
表2-9 オペレーティング・システム・ユーザーおよびグループ
| ユーザー名 | グループ | 使用者 | ログイン権限 |
|---|---|---|---|
|
|
Apache Flume親およびノード |
なし |
|
|
|
Apache HBaseプロセス |
なし |
|
|
|
なし |
||
|
|
なし |
||
|
|
Hueプロセス |
なし |
|
|
|
ResourceManager、NodeManager、Hive Thriftデーモン |
あり |
|
|
|
|
あり |
|
|
|
Oozieサーバー |
なし |
|
|
Oracle NoSQL Database、Oracle Loader for Hadoop、Oracle Data IntegratorおよびOracle DBA |
あり |
||
|
|
Puppet親( |
なし |
|
|
|
Apache Sqoopメタストア |
なし |
|
|
自動サービス・リクエスト |
なし |
||
|
|
ZooKeeperプロセス |
なし |
Oracle Big Data Applianceは、ソフトウェア・インストールのオプションとしてKerberosセキュリティをサポートしています。Kerberosで保護されているクラスタにアクセスするためのクライアントとユーザーの設定の詳細は、第3章を参照してください。
Hadoop上の通常の認可モデルはHDFSファイル・レベルであり、ユーザーはファイル内のすべてのデータへのアクセス権を持っているか、またはまったく持っていないかのどちらかです。対照的に、Apache SentryはHiveおよびImpala SQL問合せエンジンと統合され、Hadoopに格納されているデータに対するファイングレイン認証の機能を備えています。
Mammothユーティリティ・バージョン2.5より、Oracle Big Data Applianceは、ソフトウェアのインストール中にSentryを自動的に構成します。
|
関連項目:
|
オンディスク暗号化は、ディスクにあるデータを保護します。オンディスク暗号化が有効になっている場合、Oracle Big Data Applianceはディスクに格納されているデータを自動的に暗号化および復号化します。オンディスク暗号化は、パフォーマンスに若干影響する可能性はありますが、Hadoopデータへのユーザー・アクセスには影響しません。
Password-based encryption: パスワードに基づいてHadoopデータを暗号化します。パスワードは、1つのクラスタ内のすべてのサーバーで同じです。mammoth-reconfig updateコマンドを使用すると、いつでもパスワードを変更できます。詳細は、『Oracle Big Data Applianceオーナーズ・ガイド』を参照してください。
サーバーからディスクを削除した場合、サーバー(同じサーバーまたは異なるサーバー)にディスクをインストールし、サーバーを起動してパスワードを指定するまで暗号化されたデータは引き続き保護されます。サーバーの電源が切断され、Oracle Big Data Applianceラックから取り外された場合、サーバーを再起動してパスワードを指定するまで暗号化されたデータは引き続き保護されます。すべてのサーバーが起動された後、パスワードを入力してデータへのアクセスを有効にする必要があります。「Oracle Big Data Applianceの起動」を参照してください。
オンディスク暗号化は、Mammothユーティリティによる初期インストール時に選択できるオプションです。mammoth-reconfigまたはbdacliユーティリティを使用して、いつでもオンディスク暗号化を有効または無効にすることもできます。
|
関連項目: 『Oracle Big Data Applianceオーナーズ・ガイド』 |
表2-10に、CDH用のポート番号の他に使用される可能性のあるポート番号を示します。
特定のサーバー上で使用されるポート番号を確認するには、次の手順を実行します。
Cloudera Managerで、ページ上部にある「Hosts」タブをクリックして、「Hosts」ページを表示します。
「Name」列でサーバーのリンクをクリックすると、その詳細ページが表示されます。
「Ports」セクションまで下方向にスクロールします。
|
関連項目: CDHのポート番号の詳細なリストは、次に示すClouderaのWebサイトを参照してください。 |
Puppetノード・サービス(puppetd)は、すべてのサーバー上でrootとして継続的に実行されます。Puppetマスターに対する更新リクエストのトリガーとなるキック・リクエストを、ポート8139上でリスニングします。このポート上で更新は受信しません。
Puppetマスター・サービス(puppetmasterd)は、Oracle Big Data Applianceのプライマリ・ラックの第1サーバー上で、Puppetユーザーとして継続的に実行されます。ポート8140上で、Puppetノードに更新をプッシュするリクエストをリスニングします。
Puppetノードは、ソフトウェアのインストール時に初期登録するため、証明書を生成してPuppetマスターに送信します。ソフトウェアのアップデートの場合は、PuppetマスターからPuppetノードに信号(キック)が送信され、そこから登録先のPuppetマスター・ノードに対して、すべての構成変更がリクエストされます。
Puppetマスターは、既知の有効な証明書を保持しているPuppetノードに対してのみ更新を送信します。Puppetノードは、初期登録されたPuppetマスターのホスト名からの更新のみを受け付けます。Oracle Big Data Applianceでは、ラック内の通信に内部ネットワークを使用するため、Puppetマスターのホスト名は、/etc/hostsを使用して、内部のプライベートIPアドレスに解決されます。
Oracle Audit Vault and Database Firewallを使用して、Oracle Big Data ApplianceでHDFSとMapReduceの監査証跡を作成し、監視できます。
この項では、Oracle Big Data Applianceのプラグインについて次の内容を説明します。
Oracle Audit Vault and Database Firewallは、データベースや、ITインフラストラクチャで重要なその他のコンポーネントを、主として次のような形で保護します。
企業の監査プラットフォームを統合します。
Oracle Database、Oracle Big Data Appliance、オペレーティング・システム、ディレクトリ、ファイル・システムなどにおけるアクティビティを取得します。
企業全体のアクティビティを把握できるように、監査情報を単一のレポート・フレームワークで使用可能にします。各システムを個々に監視する必要はなく、コンピュータ・インフラストラクチャを全体として確認できます。
Audit Vault Serverには、管理者と監査者の両方が使用できるWebベースのグラフィカル・ユーザー・インタフェースがあります。
Oracle Big Data ApplianceでCDH/Hadoopクラスタをセキュア・ターゲットとして構成できます。Oracle Big Data ApplianceのAudit Vaultプラグインは、次のサービスから監査データとロギング・データを収集します。
Hive DDL: Hiveデータベースを誰が変更するか。
MapReduce: ファイル・アクセスに対応するMapReduceジョブを誰が実行するか。
Oozieワークフロー: 誰がワークフロー・アクティビティを実行するか。
Audit Vaultプラグインは、オプションとしてインストールされます。Mammothユーティリティは、ソフトウェア・インストール・プロセスの一部としてOracle Big Data Applianceでの監視を自動的に構成します。
|
関連項目: Oracle Audit Vault and Database Firewallの詳細は、次を参照してください。 |
プラグインの設定に必要な手順はすべて、ユーザーが指定した情報を使用してOracle Big Data ApplianceのMammothユーティリティが実行します。
Oracle Big Data Appliance用のAudit Vaultプラグインを設定するには、次の手順を実行します。
Oracle Big Data Applianceと同じネットワーク上で、Oracle Audit Vault and Database Firewall Serverリリース12.1.1が稼働していることを確認します。
|
関連項目: 『Oracle Audit Vault and Database Firewallインストレーション・ガイド』 |
Oracle Big Data Appliance構成生成ユーティリティの「Audit Vault Plug-in」セクションをすべて指定します。
Mammothユーティリティを使用して、Oracle Big Data Applianceソフトウェアをインストールします。このステップは通常、オラクル社の担当者が実行します。
bdacliまたはmammoth-reconfigを使用して、後でプラグインを追加することもできます。詳細は、『Oracle Big Data Applianceオーナーズ・ガイド』を参照してください。
ソフトウェアのインストールが完了するとOracle Big Data ApplianceにAudit Vaultプラグインがインストールされ、Oracle Audit Vault and Database Firewallがその監査情報を収集します。他のインストール手順を実行する必要はありません。
|
関連項目: Oracle Big Data Appliance構成生成ユーティリティの使用方法の詳細は、『Oracle Big Data Applianceオーナーズ・ガイド』を参照してください。 |
プラグインのインストールが終わると、他のセキュア・ターゲットと同様にOracle Big Data Applianceを監視できるようになります。Audit Vault Serverは、アクティビティ・レポートを自動的に収集します。
次の手順では、あるタイプの監視アクティビティについて説明します。
Oracle Big Data Applianceのアクティビティ・レポートを表示するには、次の手順を実行します。
Audit Vault Serverに監査者としてログインします。
「Reports」タブをクリックします。
「Built-in Reports」で、「Audit Reports」をクリックします。
すべてのアクティビティを参照するには、「Activity Reports」リストで「All Activity」のBrowse report dataアイコンをクリックします。
イベントをリストするフィルタを追加または削除します。
イベント名には、ACCESS、CREATE、DELETEおよびOPENがあります。
最初の列にあるSingle row viewアイコンをクリックして、詳細レポートを表示します。
図2-11に、アクティビティ・レポートの冒頭を示します。これには、Hadoopシーケンス・ファイルへのアクセスが記録されています。
|
関連項目: Oracle Audit Vault and Database Firewall監査者ガイド |
CDHの問題のトラブルシューティングを行うために、Oracleサポートのアドバイスが必要な場合は、まずbdadiagユーティリティをcmオプションを指定して使用し、診断情報を収集してください。
診断情報を収集するには、次の手順を実行します。
Oracle Big Data Applianceサーバーにrootとしてログインします。
少なくともcmオプションを指定してbdadiagを実行します。必要に応じてコマンドに他のオプションを含めることができます。bdadiagの構文の詳細は、『Oracle Big Data Applianceオーナーズ・ガイド』を参照してください。
# bdadiag cm
コマンド出力によって、診断ファイルの名前と場所が識別されます。
My Oracle Support (http://support.oracle.com)へ移動します。
サービス・リクエスト(SR)を開きます(まだ開いていない場合)。
SRにbz2ファイルをアップロードします。ファイルのサイズが大きすぎる場合は、sftp.oracle.comにアップロードしてください(次の手順を参照)。
診断情報をftp.oracle.comにアップロードするには、次の手順を実行します。
SFTPクライアントを開き、sftp.oracle.comに接続します。ポート2021とリモート・ディレクトリ/support/incoming/targetを指定します(targetは、Oracle Supportにより指定されたフォルダ名です)。
コマンドラインSFTPクライアントを使用している場合は、例2-1を参照してください。
Oracle Single Sign-Onのアカウントとパスワードでログインします。
診断ファイルを新しいディレクトリにアップロードします。
このフル・パスおよびファイル名でSRを更新します。
例2-1は、SFTPコマンド・インタフェースを使用して、診断情報をアップロードするコマンドを示しています。
例2-1 FTPを使用した診断情報のアップロード
$ sftp -o port=2021 my.user.name@oracle.com@sftp.oracle.com Connecting to sftp.oracle.com... . . . Enter password for my.user.name@oracle.com Password: password sftp> cd support/incoming/SR123456 sftp> put /tmp/bdadiag_bda1node01_1216FM5497_2013_07_18_07_33.tar.bz2 Uploading bdadiag_bda1node01_1216FM5497_2013_07_18_07_33.tar.bz2 to //support/incoming/create_table.sql bdadiag_bda1node01_1216FM5497_2013_07_18_07_33.tar.bz2 to support/incoming/create_table.sql 100% 311 0.3KB/s 00:00 sftp> exit $
