Oracle Big Data Appliance...すべてのドライブは、CDH（Cloudera Distribution Including...

Oracle Big Data Appliance Maximum Availability Architecture Oracle ホワイト・ペーパー | 2016 年 3 月

1 | データ共有におけるストレージ効率の最大化

目次概要 2

Oracle Big Data MAA アーキテクチャ 4

HA が内蔵されていることの利点 6

サーバー 6

ストレージ 6

接続性 7

InfiniBand スイッチ 7

配電ユニット（PDU） 8

BDA のクリティカル・ノードと非クリティカル・ノード 8

BDA のソフトウェア・コンポーネント 9

NameNode エラー! ブックマークが定義されていません。

ResourceManager 10

単一ラック内で稼働する 1 つ以上の CDH クラスタの BDA サービスの場所 11

高可用性と単一障害点 12

BDA の重要なサービスが実行される場所 12

Oracle Big Data SQL の概要 13

高可用性障害テストの主目的 14

テスト時のアプリケーション・ロード 14

MAA テスト・シナリオ 15

MAA テスト・シナリオの詳細 16

アクティブ・NameNode の障害 16

サービス移行を伴う障害 18

アクティブ・NameNode とスタンバイ・NameNode の障害 20

1 つ目の ResourceManager、Cloudera Manager、MySQL データベースの障害 22

2 つ目の ResourceManager と Hive Metastore Server の障害 26

InfiniBand スイッチの障害 29

Cisco 管理スイッチの障害 35

Big Data SQL（BDS）サーバー・プロセスの障害 35

全ノードでの Big Data SQL（BDS）サーバー・プロセスの障害 38

BDA ラックでの PDU 全体の障害 42

BDA のシステム・ディスク障害 45

BDA のデータ・ディスク障害 47


Exadata での Big Data SQL の HA テスト 48

Oracle RAC データベース・ノードの障害 48

Oracle RAC のデータベース・インスタンス障害 49

Exadata での BDA クラスタ・リソース障害 50

結論 52

付録 A 53


概要

Oracle Maximum Availability Architecture（MAA）は、実績あるオラクルの高可用性テクノロジーをベースに、専門家の提言や顧客の経験を取り入れて作ったベスト・プラクティス・ブループリントです。Oracle Big Data Appliance の設計と運用機能には MAA ベスト・プラクティスが高いレベルで統合されています。これらが一体となって、ビッグ・データ向けの極めて包括的な可用性の高いソリューションを実現します。Oracle MAA に関するホワイト・ペーパーは、Oracle Technology Network（OTN）Web サイトの MAA のホームページで公開されています。

Oracle Big Data Appliance（BDA）Maximum Availability Architecture は、Oracle の高可用性テクノロジーおよび推奨事項を使用して最適な高可用性環境を整備するためのベスト・プラクティス・ブループリントです。本書の作成にあたり、Oracle BDA の MAA テストを Oracle Big Data Appliance と Oracle Exadata Database Machine で実行し、高可用性を検証するとともにさまざまな停止シナリオにおける停止時間を測定しました。本テクニカル・ホワイト・ペーパーの今回のリリースは、Oracle BDA MAA プロジェクト全体の最初のフェーズを対象としたものです。このプロジェクトは次の 2 つのフェーズで構成されています。

フェーズ 1：単一サイトにおける高可用性と停止のシナリオ

フェーズ 2：複数サイトにおけるディザスタ・リカバリのシナリオ

Oracle Big Data Appliance は、最高のアプリケーション可用性とパフォーマンスが発揮されるように Oracle MAA 標準に従って同時並行で設計、テスト、最適化がなされたハードウェア・コンポーネントとソフトウェア・コンポーネントで構成されているエンジニアド・システムです。Oracle Big Data Appliance の特徴は次のとおりです。

» ビッグ・データに最適化された完全なソリューション

» ハードウェアとソフトウェアの両方を単一ベンダーでサポート

» デプロイが容易なソリューション

Oracle Big Data Appliance は、Hadoop システムや NoSQL システムで多様なワークロードを実行するための柔軟性に優れた高パフォーマンスかつセキュアなプラットフォームです。このプラットフォームでは、さまざまなデータソースから企業内に流入する膨大で複雑なデータ・ストリームの取得および体系化、詳細分析のサポートができます。またこのプラットフォームには、データ構造、ワークロード特性、エンドユーザー要件に応じてデータの最適な保管場所と処理場所を選択できる機能が組み込まれています。

http://www.oracle.com/technetwork/jp/content/maa-094615-ja.html


Oracle Big Data Appliance は Oracle Database および Oracle Exadata Database Machine と緊密に統合されており、オラクルと世界中の重要顧客の社内で実証されている同じ Maximum Availability Architecture が組み込まれています。Oracle Exadata Database Machine は、データウェアハウスおよびトランザクション処理データベースのホスティングに卓越したパフォーマンスを発揮します。

InfiniBand テクノロジーを使用して Oracle Big Data Appliance と Oracle Exadata Database Machine を結合すれば、スピードと効率性を最大化することができます。エンジニアド・システム同士を InfiniBand で接続すると待機時間が短縮されてスループットが向上するため、バッチ・ワークロードと問合せワークロードの高速データ送信が可能になります。

Oracle Big Data Appliance はビッグ・データを取得して体系化するためのプラットフォームで、最新のビッグ・データ・テクノロジーを使用したデータ探索やデータ分析が可能です。Oracle Database を Oracle Big Data Appliance の前に追加すれば、得られた分析結果を Oracle Databaseのデータと簡単に結合できます。Oracle Big Data SQL は複数のソースに分散しているデータを 1つにまとめ、オラクルの豊富な SQL 言語とセキュリティ・ポリシーを活用します。

Oracle Exadata の MAA ベスト・プラクティスと卓越したパフォーマンスを活用することで、高可用かつ高パフォーマンスの緊密に統合されたエンド・ツー・エンド・システムが実現します。

図1：Oracle Big Data ApplianceとOracle Exadata Database Machineは、オンプレミスでもクラウドでも実行できるように緊密に統合されています


Oracle Big Data MAAアーキテクチャ

Oracle Big Data MAA アーキテクチャは次のテクノロジーで構成されています。

» プライマリ Big Data Appliance：データ・レザボアを収容するために使用されます。データ・レザボアは、構造化データおよび非構造化データの新しいソースや大規模なソースのリポジトリとして機能し、Exadata 上で稼働しているデータウェアハウスを拡大します。データ・レザボアは、ストレージのニーズ、パフォーマンスのニーズ、および増加のニーズに対処できるように、1 つ以上の Oracle Big Data Appliance を相互接続して構成することもできます。ラックは 18 台までならスイッチを増設しなくても追加できます。

図2：情報管理の参照アーキテクチャ

» Oracle Exadata との緊密な統合により形成される Big Data Management System：メインのデータウェアハウス・システムは Exadata に保持し、会社の中核的なトランザクション・データの大半をそこに格納する必要があります。

» スタンバイ Exadata システム：Oracle Data Guard を稼働するプライマリのレプリカです。プライマリの正確な物理レプリカである同期化されたデータベースの維持管理に使用されます。

» 2 つ目の Oracle Big Data Appliance へのデータ・レプリケーション：高可用性を実現し、データ整合性を強化します。


図3：Oracle Big Data Applianceのレプリケーションによる高可用性の実現とデータ整合性の強化

» Oracle Big Data SQL：Oracle データベース、Hadoop、および NoSQL の各データソースにまたがるすべてのデータを、Oracle SQL のあらゆる機能を活用してまとめて表示できます。

» Big Data Management System：クラウド上でオラクルの Big Data Cloud Service（BDCS）と併用することもでき、オンプレミスで使用することもできます。Oracle BDCS は Exadata Cloud Service と統合されているため、すべてのデータソースに対して 1 回の高速問い合わせを実行することができます。


HAが内蔵されていることの利点

Oracle Big Data Appliance はあらゆるタイプの計画外停止に対応できるように設計されています。本書の作成にあたり、オラクルは Oracle Big Data Appliance と Oracle Exadata Database Machine に組み込まれている HA 機能を実証するためのさまざまなテストを実施しました。具体的な障害シナリオについては、本書の「MAA テスト・シナリオ」の項で説明します。

Oracle Big Data Appliance と Exadata はいずれも、ファン、PDU、バッテリ、スイッチ、ディスク、フラッシュ、データベース・サーバー、マザーボード、および DIMM といったコンポーネントでハードウェア障害が発生した後もアプリケーションをエンド・ツー・エンドで使用できるように設計および事前構成されており、広範囲に及ぶ工学的テストと統合テストによりシステムのあらゆる側面が検証されています。

Exadata の HA 機能とテストの全容については、以前のホワイト・ペーパーやドキュメントで説明しています。詳しくは、http://www.oracle.com/technetwork/jp/content/maa-094615-ja.html を参照してください。

サーバー

BDA ラックに収容されているサーバーはすべて同種であり、特殊なノードはありません。そのためどのノードにもすべてのロールを担わせることができ、サービスの移行や他のタスクへのノードの用途変更が大幅に容易になります。

サーバーには、ホットスワップ可能な冗長電源と冗長ファンの他、Integrated Lights Out Manager（ILOM）が搭載されています。

ストレージ

どの BDA サーバーでも、最初の 2 つのディスクには Linux オペレーティング・システムがインストールされています。これらのディスクには、オペレーティング・システムのミラー・コピー、スワップ・パーティション、ミラー化されたブート・パーティション、HDFS データ・パーティションが含まれています。そのため、1 つのシステム・ディスクが失われてもオペレーティング・システムを稼働し続けることができ、障害を起こしたディスクを交換する間もシステムを使い続けることができます。ミラー化されたデバイスの状態は次のコマンドで検証できます。

http://www.oracle.com/technetwork/jp/content/maa-094615-ja.html


すべてのドライブは、CDH（Cloudera Distribution Including Apache Hadoop）クラスタ（HDFS）または Oracle NoSQL Database クラスタのいずれかに属します。HDFS（Hadoop 分散システム）は複数のサーバーに広がる大規模なファイルを格納する非常にスケーラブルなファイル・システムで、ストレージ増設の必要性に合わせて迅速に拡張できます。HDFS データは 3 カ所にレプリケートされるため、データを失う可能性が低下します。

接続性

各 BDA サーバーには、デュアルポートの InfiniBand Quad Data Rate（QDR）ホスト・チャネル・アダプタ（HCA）カードが装着されています。HCA の各ポートはラックに収容されている冗長InfiniBand スイッチに接続されています。ポートまたは InfiniBand スイッチ全体が故障した場合は、アクティブなインタフェースにトラフィックがリダイレクトされるため、1 秒未満の短い停止時間が発生することがあります。

InfiniBandスイッチ

すべての BDA ノードは InfiniBand ファブリックに冗長接続されています。InfiniBand ファブリックは BDA を運用するための高パフォーマンスで高可用性のバックプレーンとして動作します。

InfiniBand ファブリックは完全に冗長化された 2 つの InfiniBand ゲートウェイ・スイッチで構築されています。1 つのスイッチが故障しても、もう 1 つの正常なスイッチによってシステム全体の機能が維持されます。InfiniBand ゲートウェイは、“リーフ”スイッチとしても、10Gb Ethernet ゲートウェイへの InfiniBand としても動作します。BDA システムの拡張を可能にする 36 ポートの“スパイン”スイッチもあります。

# cat /proc/mdstat

Personalities : [raid1]

md2 : active raid1 sda2[2] sdn2[0] 488150016 blocks super 1.1 [2/2] [UU] bitmap: 3/4 pages [12KB], 65536KB chunk

md0 : active raid1 sda1[3] sdn1[2] 194496 blocks super 1.0 [2/2] [UU]

unused devices: <none>


図4：InfiniBandゲートウェイ・スイッチのポートの位置

配電ユニット（PDU）

Oracle Big Data Appliance の配電ユニット（PDU）は高可用性を実現するために冗長化されています。この PDU により次のラック・コンポーネントの電源が冗長化されます。

» BDA ノード

» InfiniBand スイッチ

» Cisco ネットワーク・スイッチ

上のコンポーネントの電源はすべてホットスワップ対応です。各 PDU を監視すると、接続されている装置が消費している電力、エネルギー、電流がどのくらいであるか、装置に供給されている電圧レベルを調べることができます。

BDAのクリティカル・ノードと非クリティカル・ノード

クリティカル・ノードは、クラスタを正常に稼働させてユーザーがすべてのサービスを使用できるようにするために必要です。これに対し、非クリティカル・ノードで障害が発生しても、クラスタはサービスが失われることなく稼働し続けます。


シングル・ラックのクラスタでは、クラスタを構成する最初の 4 つのノードに重要なサービスが初期インストールされます。残りのノード（ノード 05～ノード 18）ではあまり重要でないサービスのみが実行されます。クリティカル・ノードのいずれかでハードウェア障害が発生した場合は、サービスを別の非クリティカル・サーバーに移動させることができます。たとえばノード 02 で障害が発生した場合は、そこで稼働していた重要なサービスをノード 05 に移動させることができます。

マルチラック CDH クラスタ上でサービスが実行される場所 1について詳しくは、Oracle Big Data のドキュメントを参照してください。

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

NameNode

すべてのデータの位置は NameNode によって追跡されるため、NameNode はもっとも重要なプロセスです。正常に稼働する NameNode がなければ、クラスタ全体が機能しません。Apache Hadoop v0.20.2 までは NameNode が 1 つであるため、障害に対して脆弱です。

CDH5 では、NameNode の冗長性を維持することで、この脆弱性を低減します。通常運用時、データは次のようにレプリケートされます。

» 冗長化された NameNode は、クラスタの最初の 2 つのノードで CDH によって維持されています。一方の NameNode はアクティブ・モードで、もう一方の NameNode はホット・スタンバイ・モードです。アクティブ・NameNode で障害が発生すると、アクティブ NameNode のロールは自動的にスタンバイ・NameNode に引き継がれます。

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

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

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

下の図は、NameNode の自動フェイルオーバーをサポートするプロセス同士の関係を示したもので

1 http://docs.oracle.com/cd/E77569_01/doc.44/e70116/

admin.htm#GUID-FE6AC362-CC4D-41C5-8860-FD2C5BED22F4

http://docs.oracle.com/cd/E77569_01/doc.44/e70116/admin.htm#GUID-FE6AC362-CC4D-41C5-8860-FD2C5BED22F4


す。

図5：Oracle Big Data ApplianceでのNameNodeの自動フェイルオーバー

ResourceManager

クラスタ内のアプリケーション・タスクおよびアプリケーション・マスターにリソースを割り当てるのが ResourceManager です。NameNode と同様、ResourceManager はクラスタの重大な障害点です。すべての ResourceManager で障害が発生すると、すべてのジョブが稼働を停止します。この脆弱性を低減するために、CDH5 を搭載した Oracle Big Data Appliance 3.0 以上で高可用性をサポートしています。

CDH はノード 03 とノード 04 で ResourceManager サービスの冗長性を維持します。一方のサービスはアクティブ・モードで、もう一方のサービスはホット・スタンバイ・モードです。アクティブ・サービスで障害が発生すると、アクティブな ResourceManager のロールは自動的にスタンバイ・サービスにフェイルオーバーされます。フェイルオーバー・コントローラは不要です。


下の図は、ResourceManager の自動フェイルオーバーをサポートするプロセス同士の関係を示したものです。

図6：Oracle Big Data ApplianceでのResourceManagerの自動フェイルオーバー

単一ラック内で稼働する1つ以上のCDHクラスタのBDAサービスの場所

ノード 01 ノード 02 ノード 03 ノード 04 ノード 05～nn

バランサ Cloudera Manager Server

Cloudera Manager Agent Cloudera Manager Agent Cloudera Manager Agent Cloudera Manager Agent Cloudera Manager Agent

DataNode DataNode DataNode DataNode DataNode

フェイルオーバー・

コントローラ

フェイルオーバー・

コントローラ

JobHistory Hive、Hue、Oozie、Solr

JournalNode JournalNode JournalNode

MySQL バックアップ MySQL プライマリ

NameNode NameNode

NodeManager NodeManager NodeManager NodeManager NodeManager

Oracle Data Integrator

Puppet Puppet Puppet Puppet Puppet

Puppet Master ResourceManager ResourceManager

ZooKeeper ZooKeeper ZooKeeper


高可用性と単一障害点

高可用性と自動フェイルオーバーが組み込まれているサービスもありますが、単一障害点を含むサービスもあります。次のリストに、重要なサービスとそれぞれの脆弱性をまとめます。

» NameNode：高可用性で自動フェイルオーバーあり

» ResourceManager：高可用性で自動フェイルオーバーあり

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

» Cloudera Manager：Cloudera Manager サーバーは 1 つのノードで実行されます。障害が発生すると、Cloudera Manager の機能は使用できなくなります。

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

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

ノード名重大な機能

1 つ目の NameNode バランサ、フェイルオーバー・コントローラ、JournalNode、

NameNode、Puppet Master、ZooKeeper

2 つ目の NameNode フェイルオーバー・コントローラ、JournalNode、 MySQL バックアップ・データベース、NameNode、Puppet、ZooKeeper

1 つ目の ResourceManager ノード Cloudera Manager サーバー、JobHistory、JournalNode、

MySQL プライマリ・データベース、ResourceManager、ZooKeeper

2 つ目の ResourceManager ノード Hive、Hue、Oozie、Solr、NodeManager、 Oracle Data Integrator エージェント、ResourceManager


上の情報は、シングル・ラック構成の BDA に該当します。マルチラックの使用例 2ではサービスの場所が異なる場合があります。ラック使用例ごとのサービスの場所について詳しくは、『Oracle Big Data Appliance ソフトウェア・ユーザーズ・ガイド』を参照してください。

Oracle Big Data SQLの概要

Hadoop システムや NoSQL システムに存在する企業データの量は増え続けています。Oracle Big Data SQL を使用すると、Hadoop システムや NoSQL システムに格納されているデータに業界標準SQL 言語でシームレスにアクセスし、Oracle Database に格納されているデータと結合することができます。

また、Hive、HDFS、Oracle NoSQL、HBase をはじめとする複数のデータソースに対する大量データの問合せを、オラクルの機能豊富な SQL 言語を使用して実行できます。Oracle Big Data SQL を使用すれば、リレーショナル・データベース、Hadoop、NoSQL をソースとするデータを 1 つの問合せに統合し、Oracle Database のセキュリティ・ポリシーをこうした外部ソースにまで拡張することができます。

Oracle Big Data SQL には、Oracle Big Data Appliance と Oracle Exadata Database Machine の緊密な統合が利用されています。また、InfiniBand 接続が待機時間の短い高帯域幅のシステム間送信を実現します。Oracle Big Data SQL では、Exadata の大幅なパフォーマンス優位性が活かされる他、Exadata に導入されているスマート・スキャン・テクノロジー（フィルタ条件のオフロード、多様な基盤テクノロジーに SQL 問合せを分散させるストレージ索引など）を使用できます。

Oracle Big Data SQL を使用すると、外部表のパフォーマンスが次世代のレベルまで向上します。外部表は、データベース外にあるデータの場所を識別および説明する Oracle Database オブジェクトです。他のデータベース表に使用するのと同じ SQL SELECT 構文を使用して、外部表を問い合わせることができます。


admin.htm#GUID-FE6AC362-CC4D-41C5-8860-FD2C5BED22F4

http://docs.oracle.com/cd/E77569_01/doc.44/e70116/admin.htm#GUID-FE6AC362-CC4D-41C5-8860-FD2C5BED22F4


図7：多様なテクノロジーに対してExadataのスマート・スキャンを実行できるようにするOracle Big Data SQL

Oracle Big Data SQL を使用すると、スマート・スキャン・テクノロジーを使用し、統一された手法で問合せができます。データの高速スキャンとフィルタ処理は Hadoop システム上のデータに対してローカルなエージェントが実行し、結合は問合せ元のデータベースで処理されます。

高可用性障害テストの主目的

本書のために行ったテストの主目的は、BDA と Exadata のラックを構成する特定の重要コンポーネントで故意に障害を発生させ、高可用性機能および MAA アーキテクチャが Big Data Management System 全体に組み込まれていることを実証することでした。

いずれのラックの要素も高可用性であると見なされた場合は、コンポーネント障害による運用上の影響をテストしてドキュメントにまとめました。該当する場合は、サービスの中断と停止時間も記載しました。

テスト時のアプリケーション・ロード

Oracle データベースから Hadoop に表をコピーする操作は、Oracle “Copy to BDA”（Oracle Big Data SQL のコンポーネント）で行いました。このプロセスの一環として、表ごとに Data Pump ファイルを作成し、Hadoop コマンドを使用して BDA 上の HDFS にコピーしました。データにアクセスできるようにするために、Data Pump ファイル上に Hive 外部表を作成しました。エンド・ツー・エンドの影響を把握するために、Exadata プラットフォーム上にある Oracle Database に Hive データ用の外部表を作成し、Exadata にあるローカル表と BDA に配置したリモート表に対して負荷テストを組み合わせて実行しました。


Swingbench 負荷生成ツールと SQL*Plus ワークロードを Exadata プラットフォームで実行しました。BDA プラットフォーム上では、Cloudera ディストリビューションに含まれている TeraGen、TeraSort、TestDFSIO、NNBench などの Hadoop のツールを利用しました。BigBench ツールも利用しました。BigBench は TPC-DS を改変したもので、ビッグ・データの業界標準パフォーマンス・ベンチマークとして推奨されています。

MAAテスト・シナリオ

次のようなハードウェア障害とソフトウェア障害を発生させて、高可用性とアプリケーションへの影響を評価しました。

(1) アクティブ・NameNode の障害

(2) サービス移行を伴う障害

(3) アクティブ・NameNode とスタンバイ・NameNode の障害

(4) 1 つ目の ResourceManager、Cloudera Manager、MySQL データベースの障害

(5) スタンバイ ResourceManager と Hive Metastore Server の障害

(6) InfiniBand スイッチの障害

(7) Cisco 管理スイッチの障害

(8) Big Data SQL（BDS）サーバー・プロセスの障害

(9) 全ノードでの Big Data SQL（BDS）サーバー・プロセスの障害

(10) BDA ラックでの PDU 全体の障害

(11) BDA のシステム・ディスク障害

(12) BDA のデータ・ディスク障害

(13) Exadata でのデータベース・ノード障害

(14) Exadata での RAC のデータベース・インスタンス障害

(15) Exadata での BDA の Clusterware リソースの障害


MAAテスト・シナリオの詳細

アクティブ・NameNodeの障害

Oracle Big Data Appliance のデプロイ環境では、2 つの NameNode を冗長化して高可用性を確保します。一方の NameNode はアクティブで、もう一方はスタンバイの状態です。このテストでは、アクティブ・NameNode・サーバーの背面から冗長電源ケーブルを両方とも引き抜くことで、擬似的にアクティブ・NameNode をクラッシュさせました。

このイベントとこれによる影響を監視するために使用したのは、Cloudera Manager、Oracle Enterprise Manager、BDA MapReduce ジョブ、および Swingbench と SQL*Plus を使用した Big Data SQL 操作です。

この状況では、2 つ目の NameNode がロールを自動的に引き継いでアクティブ・NameNode になると予測しました。2 つ目の NameNode がアクティブになると、バックアップなしで稼働を続けます。ただし、NameNode が 1 つしかないとクラスタは障害に対して脆弱で、自動フェイルオーバーに必要な冗長性はもはやありません。

1 つ目の NameNode で障害が発生している間は、次のサービスもこのノードでは使用できませんが、クラスタの可用性には影響しません。詳しくは、「BDA サービスの場所」の項を参照してください。

ノード 1 上の他のサービス：

» バランサ

» Cloudera Manager Agent

» DataNode

» フェイルオーバー・コントローラ

» NodeManager

» Puppet

» Puppet Master

» ZooKeeper

Puppet Master がこのノードで実行されており、Mammoth ユーティリティは Puppet を使用するため、このノードが停止している場合（ディスク・ドライブをラック内の別の場所に移し替える必要がある場合など）は、ソフトウェアのインストールや再インストールができません。

サーバーから冗長電源ケーブルを両方とも引き抜いてアクティブ・NameNode を故意にクラッシュさせると、クラスタ上で処理されているすべての問合せが一時的に停止しました。


図8：NameNode（ノード1）が停止している状態を表示するCloudera Managerのホストのスクリーン

図9：すべてのロールが停止していることを示すCloudera Manager


時間が少し（1 分未満）経過すると、下に示すように、2 つ目の NameNode がアクティブ・NameNode になりました。

図10：アクティブ・NameNodeのロールを引き継いだスタンバイ・NameNode（ノード2）

アクティブ・NameNode（以前のスタンバイ・ノード）が稼働し始めると問合せの処理が続行され、結果が戻されました。停止時間は 2 つ目の NameNode がアクティブになるまでに要する時間の長さに関係しますが、この状況では停止はありませんでした。

テストの目的上、クラッシュさせたノードをオンラインに戻し、スタンバイ・NameNode のロールを引き継がせました。

サービス移行を伴う障害

実際に停止した場合は、元のアクティブ・ノードを適切なタイミングで修理できれば、電源を投入して新たにスタンバイ・NameNode にすることができますが、ノード障害がさらに深刻で修理に時間がかかる場合は、bdacli コマンドを使用して非クリティカル・ノードにサービスを移行することができます。移行のおおまかな実行手順は次のとおりです。


(1) Mammoth がインストールされているノードに障害が発生した場合は、同じクラスタ内の別の非クリティカル・ノードに Mammoth バンドルをダウンロードする必要があります。

注：他のクリティカル・ノードが失われた場合は、この手順を実行する必要はありません。

a. サービスの移動先となる非クリティカル・ノードに Mammoth パッチをダウンロードします。

b. 両方のパッチを非クリティカル・ノードに解凍します。

c. 非クリティカル・ノードに Mammoth をインストールします。下に手順の例を示します。

少し時間がかかりますが、リストされているすべての手順を実行します。

(2) 新たに選択した非クリティカル・ノードからノードの移行を実行します。

# bdacli admin_cluster migrate node1

(3) ノード 1 の修理または交換が完了したら、ノード 1 をプロビジョニングし直してシステムに再度組み込むことができます。サービスを移行したノードから bdacli reprovision コマンドを実行します。

# bdacli admin_cluster reprovision node1

具体的な手順は、『Oracle Big Data Appliance ソフトウェア・ユーザーズ・ガイド』の「ハードウェア障害の管理」3の項を参照してください。


admin.htm#GUID-9AB38E1B-624E-4648-8621-BBA5F7E38F8B

# cd <patchdir>/BDAMammoth-ol6-4.3.0

# ./BDAMammoth-ol6-4.3.0.run

<output truncated> LIST OF STEPS:

Step 1 = PreinstallChecks Step 2 = SetupPuppet Step 3 = PatchFactoryImage Step 4 = CopyLicenseFiles Step 5 = CopySoftwareSource Step 6 = CreateUsers Step 7 = SetupMountPoints Step 8 = SetupMySQL Step 9 = InstallHadoop Step 10 = StartHadoopServices Step 11 = InstallBDASoftware

http://docs.oracle.com/cd/E77569_01/doc.44/e70116/admin.htm#GUID-9AB38E1B-624E-4648-8621-BBA5F7E38F8B





アクティブ・NameNodeとスタンバイ・NameNodeの障害

NameNode は重要なロールであるため、このテストでは、短時間にアクティブ・NameNode（1 つ目の NameNode）とスタンバイ・NameNode（2 つ目の NameNode）が両方ともクラッシュして停止したままになった場合の、BDA に対する運用上の影響を観察することを目的としました。それぞれの冗長電源ケーブルを引き抜いて両方のサーバーを故意にクラッシュさせました。Cloudera Manager からイベントを監視し、ワークロードに対する影響はクライアント・アプリケーションで観察しました。

NameNode が両方とも使用できないため、このケースではクラスタに障害が発生すると予測しました。アクティブ・NameNode およびスタンバイ・NameNode で稼働している他のサービスにも影響が及びます。ただし、両方の NameNode が使用できない状態ではクラスタを稼働し続けられないため、これはあまり心配することではありません。

アクティブ・NameNode の電源ケーブルを引き抜くと、スタンバイ・NameNode にアクティブ・ロールが引き継がれるため問合せが一時的（通常は 1 分未満）に中断し、ロール移行が完了すると問合せの処理が再開されました。続いて、2 つ目の NameNode（現在のアクティブ・NameNode）の電源ケーブルを引き抜きました。すると、両方の NameNode が停止し、すべての問合せ処理が停止しました。

図11：アクティブ・NameNodeが停止し2つ目のNameNodeが移行中である様子を示すCloudera Manager


図12：1分後に両方のノードが赤になったことの表示

図13：すべてのロールが赤になっているCloudera Managerのビュー

Oracle Big Data Appliance 上の Hive 表に対して Big Data SQL 問合せを実行すると、おそらく次の例と同様のエラーが返されます。


10 分後に NameNode の 1 つを再起動すると、これがアクティブ・NameNode になり、BDA で問合せの処理を続行できるようになりました。失敗した Big Data SQL 問合せはすべて再送信され、正常に終了しました。このようなタイプの停止が実際に発生した場合は、NameNode のいずれかを適切なタイミングでリカバリすることが重要です。

注：アクティブ・NameNode とスタンバイ・NameNode が高可用性構成でデプロイされているため、BDA ラックの NameNode は単一障害点（SPOF）ではありません。

1つ目のResourceManager、Cloudera Manager、MySQLデータベースの障害

ResourceManager は CDH 内の重要なサービスです。クラスタ内のアプリケーション・タスクにリソースを割り当てる役割を担っているため、ここで障害が発生するとすべてのジョブが稼働を停止します。ResourceManager の高可用性を実現するのは、元の ResourceManager が障害を起こした場合に自動的にアクティブ・ロールを引き継ぐホット・スタンバイです。

1 つ目の ResourceManager の障害時には次のサービスが中断されます。

» MySQL データベース：

Cloudera Manager、Oracle Data Integrator、Hive、および Oozie で MySQL データベースが使用されます。MySQL データベースには、Hive 表のメタデータを格納する Hive Metastore データベースが収容されています。Hive Metastore サービスは別のノードで稼働しますが、メタデータ用には MySQL データベースが使用されます。

SQL> ERROR at line 5:

ORA-29913: error in executing ODCIEXTTABLEOPEN callout

ORA-29400: data cartridge error

KUP-11504: error from external driver: oracle.hadoop.sql.xcat.common.XCatException : 321 : Error getting hive metadata. Cause : java.lang.RuntimeException:

MetaException(message:org.apache.hadoop.hive.serde2.SerDeException java.net.NoRouteToHostException: No Route to Host from exaadm06.us.oracle.com to bdanode01.us.oracle.com:8020

failed on socket timeout exception: java.net.NoRouteToHostException: No route to host; For more details see: http://wiki.apache.org/hadoop/NoRouteToHost)

http://wiki.apache.org/hadoop/NoRouteToHost)


プライマリ MySQL データベースは、2 つ目の NameNode・サーバーに配置されているバックアップ・データベースに自動的にレプリケートされるように構成されています（シングル・ラックの場合）。これがプライマリ・データベース・インスタンスのバックアップとなります。ただし、自動的にフェイルオーバーしないため、デフォルトではスタンバイはアクティブ化されません。

Cloudera Manager：

これは CDH クラスタ全体を一元管理するツールです。これがなくても、Hadoop のネイティブ・ユーティリティを使用して監視することができます。Hadoop のネイティブ・ユーティリティについては、『Oracle Big Data Appliance ソフトウェア・ユーザーズ・ガイド』の「Hadoop 監視ユーティリティの使用方法」の項 4を参照してください。

Cloudera Manager が停止した場合に代わりに使用できる Hadoop のネイティブ・ユーティリティは次のとおりです。

» YARN リソース・マネージャ・インタフェース：MapReduce ジョブの監視に利用できます。

» DFS 状態ユーティリティ：Hadoop ファイル・システムの監視に利用できます。

» Cloudera Hue：Hive データ・ストアの問合せ、Hive 表の操作、HDFS ファイルの操作、MapReduce ジョブの監視など、Hadoop に対して多数の有益な操作を実行できます。

ResourceManager の障害を擬似的に発生させるために、アプリケーション・ワークロードの実行中に 1 つ目の ResourceManager ノードの両方の冗長電源から電源ケーブルを引き抜きました。ノードが停止している間は Cloudera Manager が使用できず、Hive 表を使用する SQL セッションは続行できませんでした。つまり、MySQL データベースにある Hive Metastore を使用できないため、Hiveの操作が中断されたということです。

MySQL データベースにはスタンバイ・インスタンスがありますが、デフォルトではアクティブ化されません。プライマリ・データベースおよびバックアップ・データベースには、プライマリ・データベースからバックアップ・データベースへのレプリケーションが構成されていますが、自動フェイルオーバー機能はありません。

注：MySQL データベースの Hive Metastore に問題があっても、HDFS によるデータ・アクセスには影響せず、HDFS を使用して引き続きデータにアクセスできます。スタンバイ ResourceManager がアクティブになると、MapReduce ジョブは正常に再開されます。


admin.htm#BIGUG385

http://docs.oracle.com/cd/E77569_01/doc.44/e70116/admin.htm#GUID-FDB44A3C-29DE-4081-A559-1AE5973A9D69

http://docs.oracle.com/cd/E69290_01/doc.44/e65665/admin.htm#BIGUG385

http://docs.oracle.com/cd/E69290_01/doc.44/e65665/admin.htm#BIGUG385


Hive 表にアクセスする SQL*Plus セッションから、次の例と同様のエラーがスローされました。

Cloudera Manager が停止している場合でも、以降の図に示すとおり、モニタリング・ツールであるYARN リソース・マネージャ、DFS、および Hue ツールにはアクセスできます。

YARN リソース・マネージャには次の URL からアクセスできます。

bda1node03 は、リソース・マネージャが稼働しているサーバーです。

図14：YARNリソース・マネージャ・インタフェース

SELECT order_mode,

*

ERROR at line 1:



KUP-11504: error from external driver:

org.apache.thrift.transport.TTransportException:

java.net.SocketTimeoutException: Read timed out

http://bda1node04.example.com:8088


Hue にも引き続きアクセスできます。Hue には、Hue が稼働している次のサーバーとポート番号からアクセスできます。

図15：Hueインタフェース

DFS は Hadoop ファイル・システムの健全性を監視するのに使用され、次のように、DFS が稼働しているサーバーから使用できます。

図16：DFSはHadoopファイル・システムの健全性監視に使用できます

注：MySQL プライマリ・データベースがあるノード 3 を再起動したら、Hive 表に対する SQL 問合せが続行されます。




2つ目のResourceManagerとHive Metastore Serverの障害

このテストでは、Hive Metastore サービス、HiveServer2 および 2 つ目の ResourceManager が稼働している BDA ノードを擬似的にクラッシュさせ、クラッシュによる運用上およびパフォーマンス上の影響を判定することを目的としました。冗長電源ケーブルを両方ともサーバーから引き抜いて、スタンバイ ResourceManager ノード（シングル・ラック・デプロイメントのノード 4）を故意にクラッシュさせました。このサーバーでは下にリストしたサービスもホストされているため、サーバーがクラッシュするとサービスが中断されます。

» Oracle Data Integrator エージェント：

このサービスは、Oracle Big Data Connectors の 1 つである Oracle Data Integrator をサポートしています。ResourceManager ノードが停止しているときは Oracle Data Integrator を使用できません。

» Hive：

Hive には、HDFS に格納されているデータに対して SQL に似た操作ができるインタフェースがあります。Oracle Big Data SQL とほとんどの Oracle Big Data Connectors から Hive 表にアクセスできますが、このノードに障害が発生すると使用できなくなります。このノード上の Hive Metastore Server とは、HiveServer2 インタフェースを介して通信します。

» Hue：

ResourceManager ノードが停止しているときはこの管理ツールを使用できません。

» Oozie：

ワークフローの作成と調整を行うこのサービスは ResourceManager ノード上で動作するため、このノードが停止しているときは使用できません。

サーバーがクラッシュすると、下の図に示すように Cloudera Manager で障害が検出され、HiveServer2 と Hive Metastore Server の健全性がレポートされます。


図17：Cloudera Managerの「Clusters」→「Hive」スクリーン

下の図 18 に示すとおり、健全性テストの結果は黄色から赤に変わります。

図18：ノード4がクラッシュした後のHiveサービスのステータスを表示したCloudera Manager


下に示すように、ノード 4 が停止していることは“ホスト”のスクリーンで確認できます。

図19：ノード4が停止していることを示すCloudera Manager

Hive ノードが停止している間は、SQL を使用して Hive 表のデータにアクセスすることができませんでした。ノードがクラッシュしたときに処理中だった SQL 問合せは正常に完了し、データを返すことができましたが、ノードが停止しているときに発行した新規の SQL 問合せからは、下に示すようなエラーがスローされました。

SELECT order_mode,

*

ERROR at line 1:



KUP-11504: error from external driver: MetaException(message:Could not

connect to meta store using any of the URIs provided. Most recent

failure: org.apache.thrift.transport.TTransportException:

java.net.NoRouteToHostException: No route to host at

org.apache.thrift.transport.TSocket.open(TSocket.java:187) at

org.apache.hadoop.hive.metastore.HiveMetaStoreClient.open(HiveMetaStor

eClient.jav a:414) at

org.apache.hadoop.hive.metastore.HiveMetaStoreClient.<init>(HiveMetaSt

oreClient.j ava:234) at

oracle.hadoop.sql.xcat.hive.XCatHive.open(XCatHive.java:158)


ノードを再起動したら、問合せを続行することができました。

注：HDFS を介したデータ・アクセスには影響がありませんでした。MapReduce ジョブは完了するまで問題なく実行し続けました。

InfiniBandスイッチの障害

各 BDA ラックには 2 つの InfiniBand ゲートウェイ・スイッチが収容されています。スイッチは完全に冗長化されているため、単一障害点は発生しません。BDA ノードとスイッチ間の接続はデフォルトで均等に分散されており、各ノードの接続の半数はそれぞれのプライマリ・インタフェースで一方のリーフ・スイッチに接続され、残りの半分はプライマリ・インタフェースでもう一方のリーフ・スイッチに接続されています。

各スイッチの電源も完全に冗長化されており、各電源のステータスは、次に示すスイッチ・コマンドラインから、またはスイッチの ILOM を使用して確認できます。

スイッチとネットワークの構成は、オラクル社内でカスタマイズ、検証、テストされています。いずれかのスイッチに障害が発生した場合は、それぞれの BDA ノード上の対応するインタフェースが冗長ポートにフェイルオーバーし、サービス・レベル上の影響を最小限に抑えます。

各 BDA ホスト上の対応する InfiniBand インタフェースは bondib0 です。デフォルトでは、アクティブ・スレーブが ib0 でパッシブ・スレーブが ib1 ですが、スイッチ障害テスト時または実際の運用時にプライマリ InfiniBand スイッチに障害が発生すると、これらは変更されます。トラフィックが新しいアクティブ・インタフェースにリダイレクトされるときに、短時間の停止が確認される場合があります。

# checkpower

PSU 0 present OK

PSU 1 present OK

All PSUs OK


図20：InfiniBandスイッチ接続

BDA ノード上で現在アクティブになっているスレーブ InfiniBand インタフェースは、次のコマンドでチェックできます。

（/proc/net/bonding/bondib0 をチェックすることでも確認できます）

下に示すように、ip addr コマンドと ibstat コマンドの出力を BDA ノード上で比較すると、GUID とポート番号を確認できます。BDA ノードのポート 1 が物理的に接続されているスイッチは、この情報を使用して特定できます。

# cat

/sys/class/net/bondib0/bonding/active_slave

ib0


Oracle Big Data Appliance に対してアプリケーション・ロードを実行しながら、一方のスイッチから冗長電源ケーブルを両方とも引き抜いて InfiniBand スイッチ障害を擬似的に発生させたところ、すぐに障害が発生しました。

InfiniBand のリンクが停止すると、アクティブ・スレーブは“ib1”に切り替わり、障害が発生したスイッチに接続されていたポート“ib0”は無効とマークされます。冗長ポートへのフェイルオーバーに要する時間は、bondib0 インタフェースの BONDING_OPTS 行の downdelay パラメータで決まります。このケースでは 5000 ミリ秒（2～3 秒です）。

次の Enterprise Manager スクリーンに示すとおり、InfiniBand スイッチは Oracle Enterprise Managerに Down と表示されます。

# ip addr show ib0

7: ib0: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 65520 qdisc

pfifo_fast master bondib0 state UP qlen 1024

link/infiniband

80:00:00:4a:fe:80:00:00:00:00:00:00:00:10:e0:00:01:32:f3:b9 brd

00:ff:ff:ff:ff:12:40:1b:ff:ff:00:00:00:00:00:00:ff:ff:ff:ff

# ibstat

CA 'mlx4_0'

CA type: MT4099

Number of ports: 2

Firmware version: 2.11.1280

Hardware version: 0

Node GUID: 0x0010e0000132f3b8

System image GUID: 0x0010e0000132f3bb

Port 1:

State: Active

Physical state: LinkUp Rate: 40

Base lid: 12

LMC: 0

SM lid: 594

Capability mask: 0x02514868

Port GUID: 0x0010e0000132f3b9

Link layer: IB


図21：障害が発生したスイッチをDownとして報告するEnterprise Manager


障害が発生したスイッチの障害に関するその他の情報は、Enterprise Manager で確認できます。

図22：障害が発生したスイッチの未解決のインシデントを示すEnterprise Manager

フェイルオーバーは BDA ノードで確認できます。スイッチに障害が発生した後、アクティブ・スレーブは ib1 に変わりました。障害が発生した接続 ib0 は Down とマークされます。

# cat /sys/class/net/bondib0/bonding/active_slave

ib1

# ibstat | egrep -i 'Port|State'

Number of ports: 2

Port 1:

State: Down

Physical state: Disabled

Port GUID: 0x0010e0000132f3b9

Port 2:

State: Active

Physical state: LinkUp

Port GUID: 0x0010e0000132f3ba


下に示すような、ポートとスイッチのマッピングおよび未解決のインシデントも、Enterprise Manager の IB ファブリックのスクリーンで確認できます。

図23：IBファブリックおよびスイッチとポートとのマッピングを示すEnterprise Manager

電源を再接続し、障害が発生したスイッチをオンラインに戻すと、BDA ノードのアクティブ・ポートは再度 ib0 に切り替わりました。アプリケーションから見ると、対応する InfiniBand インタフェース上でパッシブ・スレーブがアクティブ・スレーブになったときに短い停止時間が発生しました。


Cisco管理スイッチの障害

Cisco スイッチの電源は完全に冗長化されているため、片方の電源に障害が発生しても、もう一方の電源を使用してスイッチを稼働し続けることができます。Cisco スイッチがクライアント・アプリケーションの可用性に影響を与えることはなく、データを取得するうえでも重要ではありませんが、スイッチが停止している間は管理インタフェースを使用できません。Cisco スイッチはラック内のコンポーネントの監視にも必要であるため、スイッチが停止すると ILOM イベントなどのアラートを配信できなくなります。

管理スイッチはクライアントの動作に影響しないため、単一障害点とは見なされません。

図24：Enterprise ManagerによるCiscoスイッチの監視

テストとして、Cisco スイッチの両方の電源からケーブルを引き抜いてスイッチ障害を擬似的に発生させました。アプリケーション・ワークロードは実行され続け、クライアントへの影響は確認されませんでした。

Big Data SQL（BDS）サーバー・プロセスの障害

各 Big Data Appliance ノード上で BDS サーバー・プロセスが動作しているため、BDA ノードに格納されているデータに Exadata から SQL で高パフォーマンスにアクセスできます。このプロセスは、ストレージ索引や BDA ノードへの条件のプッシュダウンといったスマート・スキャン機能をサポートしています。

BDS サーバー・プロセスが突然停止しても、同じノード上で動作している再起動プロセスによって自動的に再起動されます。問合せの処理は中断されず、プロセスは自動的に再開されます。すべての結果が問題なく返されます。


このテストでは、スクリプトを使用して BDS サーバー・プロセスを特定し、BDA ノード上でこのプロセスを停止させました。アプリケーション・ワークロードを起動し、テストを実施している間、稼働し続けました。

BDS プロセスの実行状態は、プロセスを停止するまで bdscli から確認できます。

まず、BDS サーバー・プロセスのプロセス ID を特定します。

短い kill スクリプトには次の行が含まれています。

次のようにして、特定のセル上でスクリプトを実行しました。

# bdscli -e list bdsql detail | grep bds

bdsVersion: OSS_PT.EXADOOP3_LINUX.X64_150912.1 bdsqlsrvStatus: running bdsqlmsStatus: running bdsqlrsStatus: running

# ps -ef | grep -i 'bdsqlsrv 100' | grep -v grep | awk '{print $2}' 20595

# cat bdsqlsrv_crash.sh

ps -ef | grep -i 'bdsqlsrv 100' | grep -v grep | awk '{print $2}' | xargs kill -11

# dcli -l root -c cellname -x bdsqlsrv_crash.sh


スクリプトを実行した後、2～3 秒以内で再起動（RS）プロセスによって BDS サーバー・プロセスが再起動されました。下に示すように、プロセス ID は新たに再起動されたプロセスのものに変更されていました。

bdscli から簡単なコマンドを発行して、プロセスが再度実行されていることを確認します。

必要であれば、Cloudera Manager を使用して別のホスト上で Big Data SQL プロセスを正常に再起動および停止することもできます。

図25：ノード1のBig Data SQLサーバーが停止していることを示すCloudera Manager

# ps -ef | grep -i 'bdsqlsrv 100' | grep -v grep | awk '{print $2}' 19638

# bdscli -e list bdsql detail | grep bds

bdsVersion: OSS_PT.EXADOOP3_LINUX.X64_150912.1 bdsqlsrvStatus: running bdsqlmsStatus: running bdsqlrsStatus: running


同様の情報を Enterprise Manager でも確認できます。

図26：ノード1の停止しているプロセスのステータスを示すEnterprise Manager

Big Data SQL サーバー・プロセスは各ノード上で稼働し、障害が発生した場合は自動的に再起動されます。

全ノードでのBig Data SQL（BDS）サーバー・プロセスの障害

Big Data SQL の影響とメリットを観察するために、すべての Big Data ノードで BDS サーバー・プロセスを停止しました。プロセスは監視されており、すべてのノードで自動的に再起動されるため、Cloudera Manager を使用して BDS サービスを停止し、テスト期間中プロセスが停止したままになるようにしました。

BDS サーバー・プロセスの停止による影響は、スマート・スキャンやストレージ索引といったセル・オフロード機能をデータ問合せ時に使用できないことと、パフォーマンスが低下する場合があることです。このテストでは、Exadata から起動した Big Data SQL 問合せは正常に実行されましたが、オフロード機能が使用できないため処理速度が低下しました。


図27：Cloudera ManagerからBDSサーバー・プロセスを停止した様子

すべての BDS サーバー・プロセスが停止していることを Enterprise Manager で確認します。

図28：Enterprise ManagerによるBig Data SQLサーバー・プロセスのステータスの表示


SQL 問合せを実行する前にオフロードに関する統計情報を確認しました。

SQL 問合せを起動した後で改めて統計情報を表示し、オフロードが実行されなかったことを確認しました。

SQL> SELECT sn.name,ms.value FROM V$MYSTAT ms, V$STATNAME sn WHERE ms.STATISTIC#=sn.STATISTIC# AND sn.name LIKE '%XT%';

NAME VALUE ------------------------------------------------------- ------------ cell XT granules requested for predicate offload 0 cell XT granule bytes requested for predicate offload 0 cell interconnect bytes returned by XT smart scan 0 cell XT granule predicate offload retries 0 cell XT granule IO bytes saved by storage index 0



その後、すべてのノードで BDS を再起動しました。

図29：すべてのノードのBDSプロセスを再起動するのにCloudera Managerを使用

図30：すべてのBDSサーバー・プロセスが正常に起動されたことを示すEnterprise Manager


他の SQL 問合せを実行して統計情報を再度チェックすると、BDS サーバー・プロセスが起動しているためオフロードが機能していることを確認できます。

Big Data SQL サーバー・プロセスが稼働していると、BDA ノード上で Exadata のようなスマート・スキャンを実行でき、Cloudera Manager から制御できます。障害が発生した Big Data SQL サーバー・プロセスは自動的に再起動されます。

BDAラックでのPDU全体の障害

配電ユニット（PDU）は BDA ラックごとに冗長化されています。PDU で障害が発生したり給電が停止したりすると、2 つ目の PDU からラック内のすべてのコンポーネントに電力が供給されます。

このテストでは、PDU 全体で障害が発生した後もラック内のすべてのコンポーネントが稼働し続けることを実証することを目的としました。BDA に対してアプリケーション・ロードを実行しながら、ラック内から PDU 全体を停止させ、アプリケーションへの影響がないことを検証しました。

図 31 に示すとおり、PDU-A は停止しました。Enterprise Manager で PDU 障害が検出され、アラートが発行されました。



図31：PDU障害を示すEnterprise Manager


すべての BDA ノードが稼働し続けていることを Cloudera Manager で確認しました。

図32：すべてのBDAノードが稼働し続けていることを示すCloudera Manager

BDA ノードで電源障害が検出されますが、コンポーネントごとに電源が冗長化されているため、システムへの影響はありませんでした。BDA ノード（下が bdanode ノード 1）の ILOM ログを見ると、ILOM によって電源障害が検出されたことがわかります。

19877 Sensor Log minor Tue Jan 12 15:30:08 2016

Power Supply : /SYS/PS0/STATE : Power Supply AC lost : Asserted

19878 Fault Fault critica l Tue Jan 12 15:30:18 2016

Fault detected at time = Tue Jan 12 15:30:18 2016. The suspect component: /SYS/PS0 has fault.chassis.power.ext-fail with probability=100. Refer to http://www.sun.com/msg/SPX86-8003- 73 for details.

PDU-A の電力を回復したら、電源がリストアされたことが bdanode1 の ILOM ログに示されました。

19879 Sensor Log minor Tue Jan 12 15:41:50 2016

Power Supply : /SYS/PS0/STATE : Power Supply AC lost : Deasserted

19880 Fault Repair minor Tue Jan 12 15:41:50 2016

Fault fault.chassis.power.ext-fail on component /SYS/PS0 cleared

19881 Fault Repair minor Tue Jan 12 15:41:50 2016

Component /SYS/PS0 repaired

19882 Fault UUID_ Repaired

minor Tue Jan 12 15:41:50 2016

Fault with UUID 95be9791-e28a-e687- e509-9304d6cf3135 repaired

http://www.sun.com/msg/SPX86-8003-

http://www.sun.com/msg/SPX86-8003-


BDAのシステム・ディスク障害

各 BDA ノードには、オペレーティング・システムを含むシステム・ディスクが 2 つあります。システム・ディスクは Linux MD RAID-1 デバイスを使用してミラー化されています。各ディスクには、オペレーティング・システムのコピー、スワップ・パーティション、ミラー化されたブート・パーティション、HDFS データ・パーティションが含まれています。各ノードは、1 つのシステム・ディスクが失われても停止時間なしで稼働を継続できますが、障害の発生したディスクはできるだけ早く交換してシステムに冗長性を取り戻す必要があります。

システム・ディスクを誤って引き抜いた場合は、元の場所に戻してもシステムに認識されないため、パーティション化して再度組み込む必要があります。詳しくは、『Oracle® Big Data Appliance オーナーズ・ガイド』の「サーバー・ディスクの交換」の項 5を参照してください。

高可用性を検証するために、BDA サーバーのシステム・ディスク（ディスク 0）を引き抜き、10 秒後に元に戻しました。BDA サーバーはオンラインのままで、アプリケーション・ワークロードにはシステム・ディスク障害による影響がありませんでした。ミラー・デバイスの状態を確認し、適切な処理を実施してシステムの冗長性を回復させました。

ディスクを元の場所に戻した後で、ディスクの状態をコントローラから取得しました。

『Oracle Big Data Appliance オーナーズ・ガイド』の手順に従ってディスク・ステータスを“Unconfigured(good), Spun Up”に変更し、さらに“Online, Spun Up”に変更しました。


disks.htm#GUID-56941B7D-591A-4712-8343-EA1E04DA34D8

# /opt/MegaRAID/megacli/MegaCli64 pdlist a0

Firmware state: Unconfigured(bad)

Foreign State: Foreign

http://docs.oracle.com/cd/E77569_01/doc.44/e70115/disks.htm#GUID-56941B7D-591A-4712-8343-EA1E04DA34D8


RAID パーティションのステータスは、次の例のように mdadm コマンドにパーティション番号を指定して確認できます。

# mdadm -Q --detail /dev/md2 /dev/md2:

Version : 1.1 Creation Time : Wed Jan 6 10:39:43 2016

Raid Level : raid1 Array Size : 488150016 (465.54 GiB 499.87 GB)

Used Dev Size : 488150016 (465.54 GiB 499.87 GB) Raid Devices : 2

Total Devices : 2 Persistence : Superblock is persistent

Intent Bitmap : Internal Update Time : Tue Feb 08:11:23 2016

State : active Active Devices : 2

Working Devices : 2 Failed Devices : 0 Spare Devices : 0

Name : bdanode01-adm.us.oracle.com:2 UUID : b8d19e74:4cc75e7a:11ead157:789e1074

Events : 29383 Number Major Minor RaidDevice State

0 8 210 0 active sync /dev/sdn2 2 8 2 1 active sync /dev/sda2

オペレーティング・システム・ディスクを再構築するおおまかな手順は次のとおりです。

» オペレーティング・システム・ディスクのパーティション化

» RAID アレイの修理

» オペレーティング・システム・ディスクの HDFS パーティションのフォーマット

» スワップ・パーティションのリストア

» GRUB マスター・ブート・レコードおよび HBA ブート順序のリストア


詳しくは、『Oracle Big Data Appliance オーナーズ・ガイド』の「オペレーティング・システム・ディスクの構成」6を参照してください。

BDAのデータ・ディスク障害

Hadoop は BDA ノードをまたいで 3 つのデータ・コピーを管理しています。1 つのデータ・ディスクが失われても読み取り可能なデータ・コピーが 2 つ残っているためデータは失われず、正しい数のデータ・ブロックが Hadoop によって自動的にリストアされ、冗長性が維持されます。ただし、障害が発生したドライブはできるだけ早く交換する必要があります。

擬似的にハード・ディスク障害を発生させるために、BDA サーバーからデータ・ディスクを引き抜きました。ディスクを引き抜いたことによるアプリケーション・ワークロードへの影響はありませんでした。

障害の発生したディスクを交換するには、新しいドライブを装着した後、パーティション化してフォーマットする必要があります。障害の発生したドライブを交換するおおまかな手順は次のとおりです。

» すべての HDFS パーティションのマウント解除

» ファームウェアの状態の確認（MegaCLI を使用）

» 新しいドライブのパーティション化

» パーティションのフォーマット

個別の具体的な手順は、『Oracle Big Data Appliance オーナーズ・ガイド』のデータ・ディスクの構成 7に関する項を参照してください。

新たに装着したディスクはオペレーティング・システムで同様に処理されるため、データ・ディスクの交換手順は前の項の手順とほとんど同じです。詳しい手順は、上のリンクに示した『Oracle Big Data Appliance オーナーズ・ガイド』を参照してください。


disks.htm#GUID-0BC64E2D-7D25-4C6A-B42F-B56DA6B75ACE 7 http://docs.oracle.com/cd/E77569_01/doc.44/e70115/

disks.htm#GUID-4243728C-1BD2-4810-BC08-8AB3B6D6BCE7

http://docs.oracle.com/cd/E77569_01/doc.44/e70115/disks.htm#GUID-0BC64E2D-7D25-4C6A-B42F-B56DA6B75ACE

http://docs.oracle.com/cd/E77569_01/doc.44/e70115/disks.htm#GUID-0BC64E2D-7D25-4C6A-B42F-B56DA6B75ACE

http://docs.oracle.com/cd/E77569_01/doc.44/e70115/disks.htm#GUID-4243728C-1BD2-4810-BC08-8AB3B6D6BCE7

http://docs.oracle.com/cd/E77569_01/doc.44/e70115/disks.htm#GUID-4243728C-1BD2-4810-BC08-8AB3B6D6BCE7


ExadataでのBig Data SQLのHAテスト

Oracle RACデータベース・ノードの障害

Exadata は Big Data MAA アーキテクチャの一部ですが、高パフォーマンスのスマート・スキャン・テクノロジーを使用して BDA から結果を取得できるようにするのは Big Data SQL です。Oracle RACデータベース・ノードがクラッシュした場合に Big Data SQL 操作にどのような影響があるかを評価するために、さらにテストを実施しました。

Exadata Database Machine と Oracle Big Data Appliance は、待機時間の短い高帯域幅の InfiniBandテクノロジーを使用して接続されています。Exadata で動作する 2 ノードの Oracle RAC システムをテストに使用し、Exadata 側にある Oracle RAC データベースに対してアプリケーション・ワークロードを開始しました。Hive 表は Oracle Big Data Appliance に配置されていて、これには Oracleデータベース内の外部表を使用してアクセスできます。

データベース・ノード障害を発生させることで、システムの予期しない停止を引き起こす可能性があるハードウェア障害、再起動、マザーボードおよびコンポーネントの障害の影響をシミュレーションします。このテストでは、Exadata の高可用性に関する既存の MAA テストも活用しました。Exadata の高可用性については、次の MAA ホワイト・ペーパーと Oracle ドキュメントを参照してください。

» 『Oracle Exadata Database Machine を使用した Oracle Maximum Availability Architecture の実現』8

» 『Oracle Database 高可用性ベスト・プラクティス』9

エンジニアド・システムで提供されるハードウェア、ファームウェア、およびソフトウェアが、最適なパフォーマンスと可用性を発揮できるようにチューニングされているかどうかを、Oracle Exadata のテストで確認します。Exadata は Oracle RAC テクノロジーを使用して高可用性を確保しているため、完全なノード障害が発生しても影響を最小限に抑えながらアプリケーションを稼働し続けることができます。

8 http://www.oracle.com/technetwork/jp/database/features/

availability/exadata-maa-131903-ja.pdf 9 https://docs.oracle.com/cd/E57425_01/121/HABPT/toc.htm

http://www.oracle.com/technetwork/jp/database/features/availability/exadata-maa-131903-ja.pdf

https://docs.oracle.com/cd/E57425_01/121/HABPT/toc.htm



https://docs.oracle.com/cd/E57425_01/121/HABPT/toc.htm


通常、Oracle RAC データベース・ノードで障害が発生すると、アプリケーションが一時的に停止します。これは、クラッシュしたノードが再起不能であることを残りのノードが宣言するまでに 30～60 秒の待機時間があるためです。待機時間は CSS miscount パラメータを使用して構成できます。ただし、Grid Infrastructure 12.1.0.2 BP7 以降を使用している Exadata では、ノード障害の検出時間を 2 秒以下に短縮するために InfiniBand ネットワークを使用しています。

図33：ノード・クラッシュによるアプリケーションの停止時間は、Exadata以外のシステムよりExadataのほうが短くなっています

テストの間、Oracle Big Data Appliance 上のデータに対して Exadata から Big Data SQL 問合せを実行し続けました。Exadata データベース・ノードがクラッシュした後はアプリケーションのスループットが低下してレスポンス・タイムが増加しましたが、2 秒経過すると以前の通常レベルに戻りました。ノード・クラッシュに関連してデータベースが停止することはありませんでした。

Oracle RACのデータベース・インスタンス障害

Oracle RAC のデータベース・インスタンス障害による Big Data SQL 操作に対するエンド・ツー・エンドの影響については、すでにオラクルが多数のテストを実施しています。テストでは基本的に、すべての Oracle RAC インスタンスにバランスよく接続してアプリケーション・ロードを実行しました。

Oracle RAC のデータベース・ノード上でデータベースの PMON プロセスを停止し、擬似的にインスタンスをクラッシュさせました。プロセスの停止に使用したスクリプトには、次に示すロジックが含まれています。


このようなインスタンス障害では、残っているインスタンスに 1 秒未満で接続をフェイルオーバーさせることができます。リカバリのプロセスは次の 2 つの手順で構成されます。

(1) Oracle RAC の再構成

(2) インスタンス・リカバリ

クラッシュしたインスタンスのインスタンス・リカバリは残っているインスタンスで実行します。InfiniBand ネットワークは待機時間が短く、Exadata のセルではライトバック・フラッシュ・キャッシュが使用されるため、インスタンス・リカバリ時間が大幅に短縮されます。

障害が発生したインスタンスに接続しているアプリケーションでは、数秒間の短い停止時間が想定されます。このテスト中、2 秒間アプリケーションのレスポンス・タイムが増加しました。クラスタを再構成する時間とインスタンスをリカバリする時間の分だけ停止時間が発生します。データベース停止時間が発生することは想定されておらず、このテスト中も発生しませんでした。

ExadataでのBDAクラスタ・リソース障害

Oracle Clusterware によって管理される Big Data SQL エージェントは、Exadata のデータベース・ノードごとに実行されます。エージェントは Big Data SQL のインストール時に Clusterware に登録され、エージェントの状態は次の Clusterware コマンドで確認できます。

ps -ef | grep -i ora_pmon | grep -v grep | awk '{print $2}' | xargs kill -11

# <GI_HOME>/bin/crsctl stat res -t -------------------------------------------------------------------- Cluster Resources -------------------------------------------------------------------- bds_maadb_maaclustera

1 ONLINE ONLINE exadbadm05 STABLE 2 ONLINE ONLINE exadbadm06 STABLE

# <GI_HOME>/bin/mtactl check bds_maadb_maaclustera Process "extprocbds_maadb_maaclustera -mt" running!


高可用性を実現するために、各 Exadata データベース・ノード上にエージェントが配置されます。なんらかの理由でエージェントに障害が発生した場合は、Oracle Clusterware によってエージェントが自動的に再起動されます。

このテストでは、Clusterware で制御されている BDS エージェントで障害が発生した場合に、Exadata Big Data SQL から実行している問合せにどのような影響があるかを評価しました。Exadataと Big Data Appliance でアプリケーション・ワークロードを起動した後、エージェントを停止させるスクリプトを実行しました。このスクリプトで実行した操作は次のとおりです。

extproc プロセスの停止によりただちに発生する影響は、新しい SQL 問合せで、下に示すような障害が発生するようになることです。BDS エージェントを停止した後に実行した SQL ではこのような障害が発生しましたが、実行中の問合せではデータの処理が正常に続行されました。

Big Data SQL エージェントは 10～20 秒程度で Clusterware によって再起動され、実行中の問合せは続行されると予測されます。これがテストで検証され、実行中の問合せは正常に完了しました。Big Data SQL エージェントが引き続き稼働している別の Exadata ノードで実行中の SQL には影響がありませんでした。

ps -ef | grep -i extprocbds | grep -v grep | awk '{print $2}' | xargs kill -11

SELECT SUM(amount_sold),

*

ERROR at line 1:

ORA-29913: error in executing ODCIEXTTABLEOPEN

callout


ORA-28575: unable to open RPC connection to external procedure agent

Elapsed: 00:01:02.90""


結論

Oracle Big Data MAA と Big Data Management System を組み合わせることで、ビッグ・データに使用できるもっとも包括的で可用性の高い統合ソリューションとなります。実証済みの高可用性機能が事前構成された形ですべての Oracle Big Data Appliance と Oracle Exadata システムに導入されます。また、これらの機能はオンプレミスにデプロイできるだけでなく、オラクルの Big Data Cloud Service を使用することでクラウドにもデプロイできます。

Oracle Big Data Appliance と Exadata プラットフォームを統合して Big Data Management System を構築した場合は、Oracle Big Data SQL テクノロジーを使用して優れたパフォーマンスでデータにアクセスでき、Oracle SQL の全機能を使用して Oracle Database、Hadoop、NoSQL の各ソースをまとめて表示できます。


付録A

MAA テスト・シナリオのクイック・リファレンス

障害テスト・シナリオシミュレーション・プロセスアプリケーションへの影響と期間

アクティブ・NameNode 冗長電源ケーブルをサーバーから引き抜く通常、1 分未満の短時間の停止。停止時間は、

スタンバイ・NameNode がアクティブ・

NameNode のロールを引き継ぐまでに要する時

間によって異なります。

このノード上の他のサービスは使用できません

が、クラスタの可用性には影響しません。

スタンバイ・NameNode がアクティブ・ロール

を引き継いだら、すべての問合せが続行され、

データが返されます。データ・エラーは観察さ

れませんでした。

アクティブ・NameNode と

サービス移行

冗長電源ケーブルをサーバーから引き抜く前述したとおり、スタンバイ・NameNodeがアク

ティブになるまでに短い停止時間があります。

障害が発生したサーバーをすぐにリカバリでき

ない場合は、次の構文を使用して非クリティカ

ル・ノードにサービスを移行できます。

bdacli admin_cluster migrate

アクティブ・NameNode と

スタンバイ・NameNode

冗長電源ケーブルをサーバーから引き抜く 1 つ目の NameNode から電源ケーブルを引き抜

いた後、それまでのスタンバイ・NameNode が

ロールを引き継いで処理を続行します。

残っている NameNode からも電源ケーブルを

引き抜くと、クラスタ内のすべての処理が停止

します。

電源ケーブルを元に戻すと、NameNode はアク

ティブ・NameNode として再開され、クライア

ントの処理が続行されます。



1 つ目の ResourceManager、Cloudera Manager、MySQL デー

タベース

冗長電源ケーブルをサーバーから引き抜く 1 つ目の ResourceManager で障害が発生した

場合は 2 つ目の ResourceManager がロールを

引き継ぎます。

Hive Metastore はこのノード上で稼働している

MySQL データベースに格納されています。そ

のため、Hive Metastore のメタデータが使用で

きなくなり、BDA 上の Hive 表にアクセスする

Big Data SQL 問合せの実行が停止しました。

このノードの障害により、Cloudera Manager

も停止しました。

2 つ目の ResourceManager と

Hive Metastore Server

冗長電源ケーブルをサーバーから引き抜く 2 つ目の ResourceManager で障害が発生して

もクライアント・アクセスは継続し、1 つ目の

ResourceManager がバックアップなしで稼働

を続けます。

Hive Metastore Server および HiveServer2 イン

タフェースが使用できないため、Hive 表にアク

セスする Big Data SQL 問合せの実行は停止し

ました。実行中の既存の問合せは正常に完了し

ましたが、新規の Hive 問合せは実行できませ

んでした。

HDFS を介したデータ・アクセスへの影響はあ

りませんでした。

Hue、Oozie、ODI も使用できなくなります。

InfiniBand スイッチ冗長電源ケーブルをスイッチから引き抜くスイッチは完全に冗長化されているため、単一

障害点は発生しません。各 BDA サーバーは両

方のスイッチに接続されています。トラフィッ

クがアクティブ・インタフェースにリダイレク

トされるときに 2～3 秒の停止時間が確認され

る場合があります。

Cisco 管理スイッチ冗長電源ケーブルをスイッチから引き抜く管理スイッチはクライアントの動作に影響しな

いため、単一障害点とは見なされません。

Big Data SQL（BDS）

サーバー・プロセス

サーバー・プロセスを停止させるノードごとに 1 つの BDS サーバー・プロセス

があります。障害発生時には自動的に再起動さ

れます。

全ノードでの Big Data SQL（BDS）サーバー・プロセスの障害

Cloudera Manager を使用してすべてのノードの

BDA サーバー・プロセスを停止させるスマート・スキャンやストレージ索引といったセ

ル・オフロード機能は使用できませんが、停止時

間は発生せず、問合せの処理は続行されます。



PDU 全体片方の PDU の電源を切る各 BDA ラックの PDU は冗長化されています。

PDU に障害が発生しても影響がないように、

BDA ラックのコンポーネントはすべて各 PDU

に接続されています。

BDA のシステム・ディスク障害システム・ディスク（ディスク 0 または 1）を

引き抜き、10 秒後に同じディスクをスロットに戻す

BDA システム・ディスクは RAID ミラー化を使

用して完全に冗長化されています。システム・

ディスクを引き抜いてもシステムへの影響はあ

りませんが、冗長性は低下します。

同じスロットにディスクを戻しても、RAID デ

バイスとディスク・パーティションを作り直す

必要があります。

BDA のデータ・ディスク障害データ・ディスク（ディスク 2 ～ 11 ）を引き抜き、新品のディスクと交換する

HDFSでは BDAノード間のレプリケーション係

数 3が維持されます。1つのデータ・ディスクが

失われても読取り可能なデータ・コピーがまだ 2

つあるため、データはいっさい失われません。

クライアント操作は中断なしで続行されます。

冗長性が維持されるように、正しい数のデー

タ・ブロックが Hadoop によって自動的にリス

トアされます。

Exadata での

データベース・ノード障害

冗長電源ケーブルをサーバーから引き抜く Oracle RAC のデータベース・ノードで障害が

発生すると、クラスタを検出して再構成し、イ

ンスタンスをリカバリする間の短い時間、アプ

リケーションの実行が一時的に停止します。

Exadata 以外の環境では、残っているノードが

CSS miscount パラメータに従って 30～60 秒待

機してから、クラッシュしたノードが完全に停

止したことを宣言します。

Grid Infrastructure 12.1.0.2 BP7 以降を使用して

いる Exadata では、検出時間を 2 秒以下に短縮

するために InfiniBand ネットワークを使用して

います。

2 秒間はアプリケーションのスループットが低

下し、レスポンス・タイムが増加しました。



Exadata での Oracle RAC の

データベース・インスタンス障害

インスタンス障害を擬似的に発生させるスクリプ

トを使用して、データベースの PMON プロセスを

停止させる

残っているインスタンスに 1 秒未満で接続を

フェイルオーバーさせることができます。障害

が発生したインスタンスに接続しているアプリ

ケーションでは、数秒間の短い停止時間が想定

されます。クラスタを再構成する時間とインス

タンスをリカバリする時間の分だけ停止時間が

発生します。データベース停止時間が発生する

ことは想定されておらず、このテスト中も発生

しませんでした。

InfiniBand ネットワークは待機時間が短く、

Exadata のセルではライトバック・フラッ

シュ・キャッシュが使用されるため、インスタ

ンス・リカバリ時間が大幅に短縮されます。

Exadata での BDAの Clusterware リソースの障害

Oracle Clusterware の制御下で稼働している Big Data SQL エージェントをデータベース・ノード

で停止させる

エージェントは Exadata データベース・ノード

ごとに 1 つ配置されています。

なんらかの理由でエージェントに障害が発生し

た場合は、Oracle Clusterware によってエー

ジェントが自動的に再起動されます。エージェ

ントは 10～20 秒で Clusterware によって再起動

されます。

エージェントが完全に再起動されたら、問合せ

処理が続行されます。

他のExadataデータベース・ノード上のSQL問

合せへの影響はありません。


Oracle Corporation, World Headquarters

500 Oracle Parkway

Redwood Shores, CA 94065, USA

海外からのお問い合わせ窓口

電話：+1.650.506.7000

ファクシミリ：+1.650.506.7200

C O N N E C T W I T H U S

blogs.oracle.com/oracle

facebook.com/oracle

twitter.com/oracle

oracle.com

Copyright © 2016, Oracle and/or its affiliates.All rights reserved.本文書は情報提供のみを目的として提供されており、記載内容は予告なく変更されることがあります。本文書は一切間違いがないことを保証するものではなく、さらに、口述による明示または法律による黙示を問わず、特定の目的に対する商品性もしくは適合性についての黙示的な保証を含み、いかなる他の保証や条件も提供するものではありません。オラクルは本文書に関するいかなる法的責任も明確に否認し、本文書によって直接的または間接的に確立される契約義務はないものとします。本文書はオラクルの書面による許可を前もって得ることなく、いかなる目的のためにも、電子または印刷を含むいかなる形式や手段によっても再作成または送信することはできません。 Oracle および Java は Oracle およびその子会社、関連会社の登録商標です。その他の名称はそれぞれの会社の商標です。 Intel および Intel Xeon は Intel Corporation の商標または登録商標です。すべての SPARC 商標はライセンスに基づいて使用される SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMD ロゴおよび AMD Opteron ロゴは、Advanced Micro Devices の商標または登録商標です。UNIX は、The Open Group の登録商標です。0615

Oracle Big Data Appliance...すべてのドライブは、CDH（Cloudera Distribution Including...

Documents

Transcript of Oracle Big Data Appliance...すべてのドライブは、CDH（Cloudera Distribution Including...