Skip navigation
2014

これまで、vRealize Log Insight を使用して

ためしに自分のログイン履歴を見てみました。

今回は、Interactive Analytics での分析結果を、ダッシュボードに追加してみます。

※今回も、Log Insight 2.0 を使用しています。

 

前回までのポストは・・・

Log Insight で vSphere ログイン監査。第1回(Security Dashboard から Interactive Analytics)

Log Insight で vSphere ログイン監査。第2回(Interactive Analytics での対話)

 

Interactive Analytics からのダッシュボード新規作成とチャート追加

 

Interactive Analytics のチャートをダッシュボードに追加するには、

画面左上の「Add to Dashboard」をクリックします。

今回は「New Dashboard」を選択して、ダッシュボード自体も新規作成します。

loginsight-board-01.png

 

新規作成するダッシュボードの名前を入力して、「Save」します。

ダッシュボード名は、日本語でも大丈夫そうです。

loginsight-board-02.png

 

作成したダッシュボードが選択されています。

今度は、追加するチャートの名前を入力します。チャート名も、日本語が使えました。

Notes には、なんとなくチャートの説明を記載してみます。

「Add」ボタンで、チャートが追加されます。

loginsight-board-03.png

 

追加したダッシュボードを見てみる。

 

チャートを追加したダッシュボードを見てみます。

「Dashboard」 →画面の「VMware ‐ vSphere」のあたり →「My Dashboards」 を開くと

自分で作成したダッシュボードが表示されます。

loginsight-board-04.png

 

My Dashboards を開いたら、

作成したダッシュボード(今回は「ログイン監査ダッシュボード」)をクリックします。

追加した「自分のログイン履歴」チャートが見られました。

loginsight-board-05.png

 

このチャートは、横幅を広げたり、タイトルバーをドラッグして並べ替えることもできます。

ためしに、例の赤枠のあたり(Click to expand widget)をクリックして

チャートの幅を広げてみます。

loginsight-board-06.png

 

広がりました。

loginsight-board-07.png

 

チャート追加の時に入力した「Notes」は、「i」 マークをクリックすると表示されます。

loginsight-board-08.png

 

追加したチャートは、表示期間を変更したり、

「Add Filter」 で集計するログの抽出条件を追加してすることができます。

下の例では、ためしに表示期間を変更してみました。

loginsight-board-09.png

 

ダッシュボードへのチャート追加。

 

さらに、ウィジェット(ダッシュボードにチャートやログの抽出結果など)を追加してみます。

赤枠のあたりのボタンのからでも、ウィジェットを追加することができます。

※ちなみにこれは、前回のポストで作成した分析結果の画面です。

loginsight-board-10.png

 

チャート(Chart) ウィジェットとして追加したり・・・

loginsight-board-11.png

 

Interactive Analytics 画面の下にあるように、

ログの抽出結果を表形式(Field Table)で追加したりできます。

loginsight-board-12.png

 

上記の2つのウィジェットを追加して、ウィジェットの幅を調整するとこのようになります。

簡易的な、ログイン監査ダッシュボード っぽいものができました。

表示されていた分析結果をもとに「Interactive Analytics」の画面を開いて、

更に分析をすることもできます。

チャートの虫眼鏡のマークをクリックすると・・・

loginsight-board-13.png


「Interactive Analytics」の画面が開きました。

loginsight-board-14.png

 

今回のポストでは、vCenter へのログイン履歴しか見ていませんでしたが、

工夫次第で、たとえば ESXi や BDE(Serengeti)などのログイン履歴なども

一つのダッシュボードにまとめてログイン監査したりできそうです。

 

Log Insight については、下記もどうぞ。

vCenter Log Insight のデプロイ。

vCenter Log Insight に VC 追加登録。

vCenter Log Insight を VCOPS と統合してみる。

 

以上、Log Insight でログイン履歴を見てみる話でした。

vRealize Log Insight はログ分析ツールなので、

当然ながら、収集したログを対話的に分析することができます。

 

今回も、引き続き自分のログイン履歴を見てみようと思います。

※「対話的に」というのは、UI で期間や条件を変えながら検索できるといった意味合いです。

※今回も、Log Insight 2.0 を使用しています。


前回の話はこちら。

Log Insight で vSphere ログイン監査。第1回(Security Dashboard から Interactive Analytics)

 

 

対話その1: ログの抽出期間(集計期間)を変更してみる。

 

当然ながら、Interactive Analytics の画面でもログの抽出 / 集計期間を変更することができます。

ただ、すこしわかりにくいところにある気もします。

 

例として期間設定を

2014-09-30 00:00 までから、

2014-10-01 00:00 に変更してみます。

 

Interactive Analytics 画面では、

下記の赤枠のあたりで検索期間を変更できます。

期間を入力後、Enter キーを押すか、検索ボタン で反映されます。

loginsight-login-ia-01.png

 

期間が 2014-10-01 00:00 までに変更されたことがわかります。

実は見落としているログイン履歴が 2件あったことに気づきました。

Log Insight の場合、vSphere 環境のログであれば必要なものはだいたい収集しているようなので、

このような見落とし対処などで便利かなと思いました。

loginsight-login-ia-02.png

 

対話その2: ログのフィルタをいろいろ変更してみる。


これまで自分の vCenter ログイン履歴を見てきましたが、

思っていたよりもログイン回数が少ない気がしました。

他にも、見落としているログがあるのかもしれません。


そこで、Interactive Analytics 画面で

ためしに見ていたログイン履歴の見方が妥当そうか確認してみようと思います。


まず、vCenter に確実にログインした記憶がある期間に限定して、ログを検索してみます。

2014-10-18 の1日からログ抽出してみたところ、

→なぜかログインのログが見つかりませんでした。No result です。

loginsight-login-ia-03.png


しかし、Web Client にログインして vCenter のイベント情報を見ると、確かにイベントログが残っています。

ただ、よく見ると、私の PC (192.168.0.2)からではなく、

ローカルホスト(127.0.0.1)からのログインになっています。

これは、vCenter と同じサーバにインストールされている Web Client & vCenter SSO から

vCenter にアクセスするので、ログイン元が 127.0.0.1 になってしまっていたようです。

loginsight-login-ia-04.png


Log Insight の画面に戻り、ログの抽出条件を変更してみます。

これまで、自分の PC (192.168.0.2)がログイン元であるログに絞っていましたが、

いったん条件を自分の PC 以外(does not contain)にして、他にも何かないか見てみます。

loginsight-login-ia-05.png


そうすると、Web Client にログがあったタイミングに

127.0.0.1 からのログイン履歴を見つけることができました。

チャートの、該当する部分をダブルクリックするとドリルダウンしてみることができます。

loginsight-login-ia-06.png


ドリルダウンしていくと、それらしいログを見つかりました。

ログファイル(text)のタイムスタンプは UTC でも、

timestamp では自動的に日本時間に変換してくれているようです。

 

ちなみに、私の環境では Log Insight で 2台 の vCenter を管理していて、

ログにも 2つの vCenter からのログインが見られます。

loginsight-login-ia-07.png


それでは、ログイン履歴の集計を調整してみます。

まず、ドリルダウンの時にチャートをクリックすることで追加された

Filter を「×」ボタンで削除します。

loginsight-login-ia-08.png

 

ログイン元としてに「127.0.0.1」を含む(contains)ようにします。

2つのアドレスを条件に含めるので「,」で区切っています。

 

そして、ログの集計期間も

2014-09-01 00:00 ~ 2014-10-01 00:00 の1ヶ月間にしてみました。

 

そうすると、下記のような結果になりました。

今度は 10/1 ~ 10/6 あたりに 1日あたり250件ほどの謎の大量ログインを発見しました・・・

loginsight-login-ia-09.png

 

セキュリティダッシュボードを見直してみると、

たしかに vmad\administrator ユーザは 127.0.0.1 からのログインが多いようです。

loginsight-login-ia-10.png

 

そこで、127.0.0.1 からの vmad\administrator ユーザログインを

このダッシュボードでドリルダウンしてみます。

loginsight-login-ia-11.png

 

ダッシュボードに Filter が追加され、目的のログイン情報だけが表示されました。

loginsight-login-ia-12.png

 

少し下の方をみると「vCenter Server logins by type」があり、

どのような方法でログインしたのか集計されています。

Web Client からとみられる「vim-java 1.0」からのログイン件数はそこそこです。

前掲 の Web Client ログインのイベントにもこの文字列があったので、

これが Web Client からの vCenter へのログインなのでしょう。

loginsight-login-ia-13.png

 

もう一つの「java/1.7.0_40」は

おそらく最近やった vSphere BDE(Serengeti)検証で

大量に自動ログインさせたときに発生したものと考えられます。

見づらくなるので、今回は除外してしまいます。

loginsight-login-ia-14.png

 

ノイズにになっていた「java/1.7.0_40」を除外するとこのようになりました。

だいたい期待通りの結果になりました。

1か月のうち 26日に、何らか の vCenter ログインしていたようです。

loginsight-login-ia-15.png

 

もう少し詳細にログインを分類したい場合は

Group by に Java の除外でも指定した「vmw_vc_auth_type」を含めると、

どのような方法でログインしたのか見当がつくようになります。

loginsight-login-ia-16.png

 

このように、ログイン元と、ログイン方法

(Web Client、vSphere Client、PowerCLI ・・・)

でグループ化され、色分けして表示されるようになります。

ただし、PowerCLI でも mozila~ などと表示されてしまうので、

最初は vCenter のタスク情報などからアタリをつける必要があります。

loginsight-login-ia-17.png

 

これまでの感想。

 

  • 人間がログインして作業するユーザと、システム利用ユーザ(LogInsight や、VCOPS からの接続など)は別にしておかないと、ログイン監査も大変になる。
  • ログイン監査をするときは、色々なログインを試して、ちゃんと監査できるか妥当性を確認したほうがよい。
  • localhost(127.0.0.1)はログ出力したサーバ自身なので、どのサーバかわかりにくい。
    どこが生成したログなのか確認するには、ログにあるアドレス以外の情報も必要になることが多そう。
  • とりあえずログを収集しておけば、後から「やっぱりこれも検索」ができる。

 

まだつづく・・・

Log Insight で vSphere ログイン監査。第3回(Add to Dashboard)

vRealize Log Insight 2.0 には、デフォルトで

vSphere 環境のログ解析に特化したダッシュボードが含まれています。

 

今回はその中の Security ダッシュボードを利用して、

ためしに私自身の vCenter ログイン履歴を見てみようと思います。

※今回も、Log Insight 2.0 を使用しています。

 

Log Insight についてはこのあたりもどうぞ。

vCenter Log Insight のデプロイ。

 

今回やってみること

  • 自分がどれくらい vSphere 環境にアクセスしていたのか見てみる。
  • これまで私が vSphere 環境を操作するためのログインでは、vmad\administrator ユーザだけ使用している。
  • ログイン元の PC は 1台(IP アドレスは 192.168.0.2)だけ。
  • vCenter へのログイン履歴だけ見てみる。ESXi などを見ることも可能だが今回は無視。
  • 1か月分のログイン情報を見てみる。(2014年 9月1日~30日)

 

 

vCenter へのログイン回数を見てみる

 

まず Log Insight の Web UI にログインします。

loginsight-sec-01.png


Dashboard → General → 「VMware - vSphere」を開きます。

loginsight-sec-02.png


vSphere 環境用にカスタマイズされたダッシュボード群が表示されました。

「General - Security」を表示します。

ログの表示期間を「Custom time range」にします。

loginsight-sec-03.png

 

期間を 2014年 9月1日~30日にして「Update」します。

loginsight-sec-04.png

 

選択した期間のログ解析結果が表示されます。

アクセス元ごとの、vCenter へのログイン履歴

「vCenter Server successful logins by user and source」を見てみます。


vmad\administrator ユーザのログイン履歴だけ注目してみます。

期間中に、私の PC(192.168.0.2)から の vmad\administrator ユーザログインは

55回ぐらいあったようです。

loginsight-sec-05.png

 

他のサーバから

vmad\administrator ユーザの大量ログインが発生していますが、

これは Log Insight サーバからの vCenter ログインでした。

※Log Insight への vCneter 接続ユーザを別にした方がよかった気もします。

 

127.0.0.1(ループバックアドレス)による vCenter のサーバ内からの

ログインも結構ありますが、今回は気にしません。

loginsight-sec-05li.png

 

 

日ごとの ログイン履歴を見てみる

 

ここからは、

私の PC のログインがいつあったのか、日ごとに見てみようと思います。

対話形式の分析(Interactive Analytics)ができる画面を見てみようと思います。


表示されているチャートのうち、分析したい部分をクリックして、

「Interactive Analytics」をクリックします。

loginsight-sec-06.png


Interactive Analytics の画面に切り替わり、少し待つと、チャートが表示されます。

loginsight-sec-07.png

 

チャートを表示されたら、少し調整します。

  • ログの発生した回数「Count」にする。
  • 時系列で表示したいので「Time series」を選択して「Apply」。

loginsight-sec-08.png

 

もう少し調整します。

  • チャートの横軸を、1日単位「1 day」にする。
  • チャートの種類を、棒グラフ「Column」にする。

loginsight-sec-09.png

 

こんな感じになります。

画面の中段には、ログの抽出条件(Filter)、

画面下には実際のログも表示されます。


29日間で、13日に何かしらログインしていたようです。

29日間・・・・ 2014-09-30 00:00 までではなくて

2014-09-30 23:59 や2014-10-01 00:00 にすべきでした。

loginsight-sec-10.png

 

それにしても、思ったよりもログインしていない日が多いような。

しかし、あえて、このまま、つづく・・・

Log Insight で vSphere ログイン監査。第2回(Interactive Analytics での対話)

vSphere Big Data Extentions(BDE)の

Hadoop クラスタで Elastic Scaling を有効化してみました。


これまでの話は・・・

vSphere BDE で Elastic Scaling してみる。第1回

vSphere BDE で Elastic Scaling してみる。第2回(Compute-only Hadoop Cluster)

 

Elastic Scaling により、 BDE で構築した Compute-only Hadoop Cluster の

スレーブノード数(MapReduce の TaskTracker)が自動増減します。

ここでの「Compute-only」とは MapReduce と HDFS のうち、

「MapResuce 部分だけ」のクラスタということです。

※HDFS などのデータ格納領域は別途用意する想定の構成です。


ちなみに Elastic Scaling の設定は、BDE で Hadoop クラスタを

停止→起動するたびに Manual に戻るようになっているようなので、

有効化する場合は Hadoop クラスタを起動するたびに再設定します。

 

 

Elastic Scaling の設定(Web Client + BDE プラグインの場合)

 

Elastic Scaling はデフォルトでは無効なので、Elasticity Mode は「Manual」です。

「1 ComputeMaster」で「DataMaster」がないことから、

Compute-olny のクラスタ(HDFS が含まれない)クラスタであることがわかります。

bde-elastic scaling-01.png


Elastic Scaling を設定するクラスタを右クリックして

「Set Elasticity Mode」を開きます。

bde-elastic scaling-02.png


Elasticity Mode で「Auto」を選択して、

スレーブノード(Compute nodes)の最大数、最小数を設定します。

bde-elastic scaling-03.png

 

Elastic Scaling が有効化され、Elasticity Mode は「Auto」になりました。

bde-elastic scaling-04.png

 

 

Elastic Scaling の設定(Serengeti CLI の場合)

 

BDE 管理サーバの Serengeti CLI からでも Elastic Scaling を有効化できます。

 

Serengeti CLI についてはこちらもどうぞ。

vSphere で Hadoop してみる。BDE 第6回(Serengeti CLI)

 

デフォルトだと、Elastic Scaling は無効(AUTO ELASTIC : Disable)です。

serengeti> cluster list --name mr_cluster01

  ============================================================================

 

  CLUSTER NAME              :  mr_cluster01

  AGENT VERSION             :  2.0.0

  DISTRO                    :  apache

  TOPOLOGY                  :  HVE

  AUTO ELASTIC              :  Disable

  MIN COMPUTE NODES NUM     :  Unset

  MAX COMPUTE NODES NUM     :  Unset

  IO SHARES                 :  NORMAL

  STATUS                    :  RUNNING

  EXTERNAL HDFS             :  hdfs://192.168.5.145:8020

 

  GROUP NAME     ROLES                                    INSTANCE  CPU  MEM(MB)  TYPE    SIZE(GB)

  ------------------------------------------------------------------------------------------------

  ComputeMaster  [hadoop_jobtracker]                      1         1    3748     SHARED  10

  Worker         [hadoop_tasktracker]                     3         1    3748     LOCAL   20

  Client         [hadoop_client, pig, hive, hive_server]  1         1    3748     SHARED  20

 

  ============================================================================

 

Elastic Scale を有効にしてみます。

Serengeti CLI の「cluster setParam ~」で設定します。

  • --elasticityMode AUTO → 「AUTO」だと自動スケールします。
  • --minComputeNodeNum 2 → スレーブノードの最小数です。
  • --maxComputeNodeNum 3 → スレーブノードの最大数です。

serengeti> cluster setParam --name mr_cluster01 --elasticityMode AUTO --minComputeNodeNum 2 --maxComputeNodeNum 3

cluster mr_cluster01 adjusted

 

有効化すると「AUTO ELASTIC : Enable」になります。

MIN COMPUTE NODES NUM と MAX COMPUTE NODES NUM も設定されました。

serengeti> cluster list --name mr_cluster01

  ============================================================================

 

  CLUSTER NAME              :  mr_cluster01

  AGENT VERSION             :  2.0.0

  DISTRO                    :  apache

  TOPOLOGY                  :  HVE

  AUTO ELASTIC              :  Enable

  MIN COMPUTE NODES NUM     :  2

  MAX COMPUTE NODES NUM     :  3

  IO SHARES                 :  NORMAL

  STATUS                    :  RUNNING

  EXTERNAL HDFS             :  hdfs://192.168.5.145:8020

 

  GROUP NAME     ROLES                                    INSTANCE  CPU  MEM(MB)  TYPE    SIZE(GB)

  ------------------------------------------------------------------------------------------------

  ComputeMaster  [hadoop_jobtracker]                      1         1    3748     SHARED  10

  Worker         [hadoop_tasktracker]                     3         1    3748     LOCAL   20

  Client         [hadoop_client, pig, hive, hive_server]  1         1    3748     SHARED  20

 

  ============================================================================

 

ちなみにこの機能は、デプロイ済みのスレーブ用 VM を 自動起動 / 自動停止します。

自動クローンでノード追加したりするような機能ではなく

maxComputeNodeNum を TaskTracker VM 数よりも多くしたりできません。

※今回のスレーブノードは 3 VM です。

serengeti> cluster setParam --name mr_cluster01 --elasticityMode AUTO --minComputeNodeNum 2 --maxComputeNodeNum 5

cluster mr_cluster01 setParam failed: Invalid value: maxComputeNodeNum=5. Value must be less than or equal to the number of compute-only nodes (3) and greater than or equal to minComputeNodeNum (2).

serengeti>

 

 

自動スケールイン / スケールアウトの様子

 

BDE の Elastic Scaling では、

自動スケールイン(ノード削除) / スケールアウト(ノード追加)は

クローン済みの VM を 停止 / 起動 することで実現されます。


たとえば、Hadoop クラスタではデフォルトでは

デフォルトではスレーブノード(Worker)がすべて起動されています。

bde-elastic scaling-05.png

 

Elastic Scaling を有効にすると

リソースに余裕がある状態では

自動的にスレーブノードが停止されます。(スケールイン)

bde-elastic scaling-06.png


リソースに余裕がなくなると

自動的にスレーブノードが起動され、クラスタに組み込まれます。(スケールアウト)

bde-elastic scaling-07.png


Web Clientの「ホストおよびクラスタ」のインベントリでも

「監視」→「タスク」タブで様子が見られます。

bde-elastic scaling-08.png


BDE 管理サーバのログファイル(/opt/serengeti/logs/serengeti.log)にも

スレーブノードの停止 / 起動 の様子が出力されます。


スレーブノードの停止

[2014-10-10T23:21:29.742+0000] INFO  pool-2-thread-5| com.vmware.bdd.service.event.VmEventManager: synced power state poweredOff on vm: null:VirtualMachine:vm-346

[2014-10-10T23:21:29.749+0000] INFO  pool-2-thread-5| com.vmware.bdd.service.event.VmEventManager: received vm Powered Off event for vm: mr_cluster01-Worker-2

 

スレーブノードの起動

[2014-10-10T16:19:58.269+0000] INFO  pool-2-thread-3| com.vmware.bdd.service.event.VmEventManager: synced power state poweredOn on vm: null:VirtualMachine:vm-347

[2014-10-10T16:19:58.275+0000] INFO  pool-2-thread-3| com.vmware.bdd.service.event.VmEventManager: received vm Powered On event for vm: mr_cluster01-Worker-1

 

マニュアルだと、下記のあたりです。

VMware vSphere Big Data Extensions Administrator's and User's Guide

  > Managing Hadoop and HBase Clusters

About Resource Usage and Elastic Scaling

 

BDE については、こちらもどうぞ。

vSphere で Hadoop してみる。(Big Data Extentions) 第1回

vSphere BDE(Hadoop)と vSphere HA の関係について。

vSphere BDE の Hadoop 的なデータストア活用について。(Local / Shared)

vShere BDE の Hadoop 的なトポロジ認識について。(Rack awareness と HVE)

 

以上、BDE の Elastic Scaling についてでした。

今回は、vSphere Big Data Extentions(BDE)で

Elastic Scaling をためす準備として

Compute-only の Hadoop クラスタを作成してみました。


前回はこちらです。

vSphere BDE で Elastic Scaling してみる。第1回

 

Compute-only Hadoop Cluster とは


ベーシックな Hadoop クラスタでは

MapReduce の計算ノードと、HDFS によるデータ格納ノードがありますが、

そのうち 計算ノードだけ(Compute-Only)のクラスタを作成することができます。

この場合、データの格納場所には既存の Hadoop の HDFS クラスタや、

HDFS としてアクセスできるストレージ領域(たとえば EMC の Isilon や ViPR とか)を

利用できるようです。

 

BDE で Apache Hadoop のCompute-only クラスタを作成すると、

下記のノードが作成されます。

  • MapReduce のJobTracker  1ノード
  • MapReduce のTaskTracker  複数ノード
  • Hadoop クライアント 複数ノード

 

BDE の Elastic Scaling を利用する場合もこのクラスタにする必要があるようなので、

今回はそのためだけに Compute-only クラスタを作成してみます。

 

Compute-only Hadoop Cluster の作成

 

これまでの Hadoop クラスタ作成と同様に、

BDE の Web Cliet プラグインの「Create New Big Data Cluster」から作成します。


Deployment Type で「Compute-only Hadoop Cluster」を選択します。

そして、DataMaster URL に

作成するクラスタがアクセスする HDFS の URL を指定します。

bde-compute-only-01.png

 

確認画面は下記のような感じです。

Topology では HVE が指定できます。

表示はされていませんが、HDFS の URL は指定できています。

bde-compute-only-02.png

 

作成したクラスタには、

DataMaster が含まれていません。

そして、ベーシックな Hadoop クラスタでは「N/A」だった

Elasticity Mode が「Manual」になっています。

bde-compute-only-03.png


Serengeti CLI からこの Hadoop クラスタを見てみました。

Elasticity Mode が「Manual」なので、

Elastic Scaling は無効な状態(AUTO ELASTIC : Disable)です。

hadoop_namenode と hadoop_datanode は含まれません。

「EXTERNAL HDFS」に URL が指定されています。

serengeti>cluster list --name mr_cluster01

  ============================================================================

 

  CLUSTER NAME              :  mr_cluster01

  AGENT VERSION             :  2.0.0

  DISTRO                    :  apache

  TOPOLOGY                  :  HVE

  AUTO ELASTIC              :  Disable

  MIN COMPUTE NODES NUM     :  Unset

  MAX COMPUTE NODES NUM     :  Unset

  IO SHARES                 :  NORMAL

  STATUS                    :  RUNNING

  EXTERNAL HDFS             :  hdfs://192.168.5.145:8020

 

  GROUP NAME     ROLES                                    INSTANCE  CPU  MEM(MB)  TYPE    SIZE(GB)

  ------------------------------------------------------------------------------------------------

  ComputeMaster  [hadoop_jobtracker]                      1         1    3748     SHARED  10

  Worker         [hadoop_tasktracker]                     3         1    3748     LOCAL   20

  Client         [hadoop_client, pig, hive, hive_server]  1         1    3748     SHARED  20

 

  ============================================================================

 

この Hadoop クラスタに Serengeti CLI で接続して

「cfg info」を見てみると、クラスタ作成時に指定した

HDFS の URL が設定されています。

serengeti>cluster target --name mr_cluster01

serengeti>cfg info

Hadoop [1.2.1 rev.1503152][fs=hdfs://192.168.5.145:8020][jt=192.168.5.148:8021]

 

以上、BDE で Compute Only のクラスタを作成してみる話でした。

まだつづく・・・

vSphere Big Data Extentions(BDE) では

Hadoop のスレーブノードを、後から追加したりできます。

手動でのスケールアウトだけでなく、

Elastic Scaling という自動でのノード増減機能もあります。

 

今回は、手動でのノード追加(スケールアウト)を、

BDE の Web Client プラグインから実行してみました。


BDE のセットアップについては、こちらをどうぞ。

vSphere で Hadoop してみる。(Big Data Extentions) 第1回

 

手動でのスケールアウト

 

BDE の Web Cliet プラグインの「Big Data Clusters」画面を開いて、

スレーブノードのスケールアウトをしたいクラスタで

右クリックして「Scale Out」をクリックします。

bde-manual-scale-out-01.png

 

スレーブノード(worker)の、

スケールアウト後の台数を指定します。

今回は、3台から5台に台数を増やしてみます。

bde-manual-scale-out-02.png

 

クラスタの Status が Updating になります。

Worker を 5 VM に拡張中です。

bde-manual-scale-out-03.png


しばらく待つと完了して、Status が Running になります。

bde-manual-scale-out-04.png

 

自動スケールアウトについて

 

BDE には、さらに

自動的に Hadoop のスレーブノード数を増減させる

Elastic Scaling という機能があります。

 

この機能は、スレーブノードのうち Compute Node を対象とします。

ここでの Compute Node は、MapReduce の TaskTracker のことです。


BDE で作成した

スレーブノードが「DataNode + TaskTracker」になっているクラスタでは

Elastic Scaling を有効にすることはできませんでした。

「cluster setParam」コマンドも、Compute Only のクラスタでないとダメなようです。

serengeti>cluster list --name hdp_cluster03

  ============================================================================

 

  CLUSTER NAME              :  hdp_cluster03

  AGENT VERSION             :  2.0.0

  DISTRO                    :  apache

  AUTO ELASTIC              :  N/A ★自動スケールアウトは無効状態。

  MIN COMPUTE NODES NUM     :  N/A

  MAX COMPUTE NODES NUM     :  N/A

  IO SHARES                 :  NORMAL

  STATUS                    :  RUNNING

 

  GROUP NAME  ROLES                                    INSTANCE  CPU  MEM(MB)  TYPE    SIZE(GB)

  ---------------------------------------------------------------------------------------------

  master      [hadoop_namenode, hadoop_jobtracker]     1         2    7500     SHARED  50

  worker      [hadoop_datanode, hadoop_tasktracker]    5         1    3748     LOCAL   50

  client      [hadoop_client, pig, hive, hive_server]  1         1    3748     SHARED  50

 

  ============================================================================

 

serengeti>cluster setParam --name hdp_cluster03 --elasticityMode AUTO --minComputeNodeNum 2 --maxComputeNodeNum 6

cluster hdp_cluster03 setParam failed: If the cluster is MRv1, then it must have compute only node group(s), and set/resetParam is only applicable to compute only node groups. On the other hand, we do not support elasticity on MRv2 (YARN) clusters yet.

 

だめでした。

というわけで、TaskTracker だけのスレーブノードをもつクラスタを作成して

Elastic Scaling を試してみようと思います。

 

つづく・・・

vSphere BDE で Elastic Scaling してみる。第2回(Compute-only Hadoop Cluster)

 

vSphere Big Data Extensions(BDE)では、

コマンドラインのツール(Serengeti CLI)から

Hadoop クラスタを自動構築することもできます。

 

今回は、Serengeti CLI の「cluster create ~」で作成したクラスタが

ほとんどデフォルトの状態でどのような構成になるのか見てみようと思います。


Serengeti-CLI については、こちらもどうぞ。

vSphere で Hadoop してみる。BDE 第6回(Serengeti CLI)

 

Serengeti CLI での Hadoop クラスタ作成

 

まず、serengeti で、BDE の管理サーバに接続します。

BDE の管理サーバ(management-server VM)に SSH でログインして、

そこから Serengeti CLI を起動します。

[serengeti@192 ~]$ serengeti

=================================================

*  _____                                 _   _  *

* / ____|  ___ _ __ ___ _ __   __ _  ___| |_(_) *

* \____ \ / _ \ '__/ _ \ '_ \ / _` |/ _ \ __| | *

*  ____) |  __/ | |  __/ | | | (_| |  __/ |_| | *

* |_____/ \___|_|  \___|_| |_|\__, |\___|\__|_| *

*                             |___/             *

*                                               *

=================================================

Version: 2.0.0

Welcome to Serengeti CLI

serengeti>connect --host localhost:8443

Enter the username: vmad\administrator ★vCenterSSO 認証できるユーザでログイン。

Enter the password: **********

Connected

serengeti>

 

BDE には、ディストリビューションを追加していないので、

デフォルトの「apache」(Apache Hadoop 1.2.1)が使われます。

serengeti>distro list

  NAME    VENDOR  VERSION  HVE    ROLES                                                                                                                                                                   

  ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

  apache  Apache  1.2.1    true   [hadoop_client, hadoop_datanode, hadoop_jobtracker, hadoop_namenode, hadoop_tasktracker, hbase_client, hbase_master, hbase_regionserver, hive, hive_server, pig, zookeeper]

  bigtop  BIGTOP  0.7.0    false  [hadoop_client, hadoop_datanode, hadoop_journalnode, hadoop_namenode, hadoop_nodemanager, hadoop_resourcemanager, hbase_client, hbase_master, hbase_regionserver, hive, hive_server, pig, zookeeper]

 

vCenter で既にリソースプールが作成してあり、

BDE 側では「auto--~」という名前で自動認識されています。

今回は「hdp_pool01」というリソースプールに Hadoop クラスタを作成しようと思うので、

「auto--4278031577701708056」を create コマンドに指定します。

serengeti>resourcepool list

  NAME                       PATH

  ----------------------------------------------------------

  defaultRP                  cluster01_mgmt/

  auto--4278031577701708056  cluster02/hdp_pool01

  auto--6950730206449699834  cluster02/sv-pool01

 

Hadoop クラスタで使用するつもりの データストアも、BDE に登録してあります。

※これらは、以前に手動登録しました。

serengeti>datastore list

  NAME                TYPE    REG EX

  ----------------------------------

  defaultDSLocal      LOCAL   FALSE

  ds_local_hadoop_01  LOCAL   FALSE

  ds_local_hadoop_02  LOCAL   FALSE

  ds_local_hadoop_03  LOCAL   FALSE

  ds_local_hadoop_04  LOCAL   FALSE

  ds_nfs_hadoop_01    SHARED  FALSE

 

Hadoop クラスタのノードが接続するポートグループも、BDE に登録してあります。

※これも、以前に手動登録しました。

今回は、vCenter の「dvpg-vlan-0005」というポートグループを使用するつもりなので

コマンドでは、BDE に登録する時につけた「bde-vlan-0005」という名前を指定します。

serengeti>network list

  NAME            PORTGROUP       TYPE  IP_RANGES  DNS1  DNS2  GATEWAY  MASK

  --------------------------------------------------------------------------

  defaultNetwork  pg-vlan-0005    dhcp

  bde-vlan-0005   dvpg-vlan-0005  dhcp

 

それでは、Hadoop クラスタ作成コマンドを実行してみます。

今回指定したパラメータは、下記の3つだけです。

  • --name → 新規作成する Hadoop クラスタの名前
  • --rpNames → Hadoop クラスタを作成するリソースプール
  • --networkName → クラスタノードが利用する、BDEポートグループ

serengeti>cluster create --name hdp_cluster03 --rpNames auto--4278031577701708056 --networkName bde-vlan-0005

 

コマンドを実行すると、下記のような進捗表示になります。

STARTED 0%

 

node group: master,  instance number: 0

roles:[hadoop_namenode, hadoop_jobtracker]

 

node group: worker,  instance number: 0

roles:[hadoop_datanode, hadoop_tasktracker]

 

node group: client,  instance number: 0

roles:[hadoop_client, pig, hive, hive_server]

 

ちなみに、Serengeti-CLI の「cluster create ~」では、

他にも下記のようなパラメータが指定できます。※下記以外にもいくつかあります。

  • --type → Hadoop / HBase どちらのクラスタか
  • --distro → Hadoop ディストリビューション
  • --networkName → Hadoop クラスタで使用する NW(ポートグループ)を指定する。
  • --hdfsNetworkName → HDFS の NW を分ける場合に指定する。
  • --mapredNetworkName → MapReduce の NW を分ける場合に指定する。
  • --topology → トポロジ。HOST_AS_RACK、HVE など
  • --password → Hadoop ノードに設定するパスワード
  • --specFile →クラスタ構成をファイルで指定することもできる。

 

詳しくは下記のあたりを参照・・・

VMware vSphere Big Data Extensions Command-Line Interface Guide

> Serengeti CLI Command Reference

> cluster Commands

cluster create Command

 

 

クラスタ自動構築の様子

 

徐々にクラスタが構築されていきます。

STARTED 22%

 

node group: master,  instance number: 1

roles:[hadoop_namenode, hadoop_jobtracker]

  NAME                    IP  STATUS     TASK

  -------------------------------------------------

  hdp_cluster03-master-0      Not Exist  Cloning VM

 

node group: worker,  instance number: 3

roles:[hadoop_datanode, hadoop_tasktracker]

  NAME                    IP  STATUS       TASK

  ---------------------------------------------------------

  hdp_cluster03-worker-0      Not Exist    Cloning VM

  hdp_cluster03-worker-1      Not Exist    Cloning VM

  hdp_cluster03-worker-2      Powered Off  Reconfiguring VM

 

node group: client,  instance number: 1

roles:[hadoop_client, pig, hive, hive_server]

  NAME                    IP  STATUS       TASK

  ---------------------------------------------------------

  hdp_cluster03-client-0      Powered Off  Reconfiguring VM

 

ジョジョにクラスタが構築されていきます。

この画面は Ctrl+C キーなどで抜けてしまっても、自動構築は止まらないようです。

STARTED 78%

 

node group: master,  instance number: 1

roles:[hadoop_namenode, hadoop_jobtracker]

  NAME                    IP             STATUS    TASK

  -----------------------------------------------------------------

  hdp_cluster03-master-0  192.168.5.138  VM Ready  Bootstrapping VM

 

node group: worker,  instance number: 3

roles:[hadoop_datanode, hadoop_tasktracker]

  NAME                    IP             STATUS    TASK

  --------------------------------------------------------------------------

  hdp_cluster03-worker-0  192.168.5.129  VM Ready  Formatting data disks

  hdp_cluster03-worker-1  192.168.5.128  VM Ready  Installing package hadoop

  hdp_cluster03-worker-2  192.168.5.137  VM Ready  Formatting data disks

 

node group: client,  instance number: 1

roles:[hadoop_client, pig, hive, hive_server]

  NAME                    IP             STATUS    TASK

  -----------------------------------------------------------------

  hdp_cluster03-client-0  192.168.5.139  VM Ready  Bootstrapping VM

 

ちなみに、上記の状態は、BDE の Web Client プラグインからも確認できます。

Task 列にも、上記と同じものが表示されています。

bde-cli-cluster-create-01.png

 

Serengeti-CLI から「cluster list ~」コマンドで

デプロイ処理中の Hadoop クラスタを表示すると、

STATUS が PROVISIONING になっています。

serengeti>cluster list --name hdp_cluster03

  ============================================================================

 

  CLUSTER NAME              :  hdp_cluster03

  AGENT VERSION             :  2.0.0

  DISTRO                    :  apache

  AUTO ELASTIC              :  N/A

  MIN COMPUTE NODES NUM     :  N/A

  MAX COMPUTE NODES NUM     :  N/A

  IO SHARES                 :  NORMAL

  STATUS                    :  PROVISIONING

 

  GROUP NAME  ROLES                                    INSTANCE  CPU  MEM(MB)  TYPE    SIZE(GB)

  ---------------------------------------------------------------------------------------------

  master      [hadoop_namenode, hadoop_jobtracker]     1         2    7500     SHARED  50

  worker      [hadoop_datanode, hadoop_tasktracker]    3         1    3748     LOCAL   50

  client      [hadoop_client, pig, hive, hive_server]  1         1    3748     SHARED  50

 

  ============================================================================

 

 

構築された Hadoop クラスタの様子

 

自動構築が完了すると、cluster list コマンドでは

STATUS が「RUNNING」になります。

トポロジ指定(HOST_AS_RACK、HVE など)は、デフォルトではないようです。

HDFS / MapReduce のマスタノードは、「master」として 1つの VM にまとめられています。

スレーブノード(DataNode + TaskTracker)は 3台作成されます。

serengeti>cluster list --name hdp_cluster03

  ============================================================================

 

  CLUSTER NAME              :  hdp_cluster03

  AGENT VERSION             :  2.0.0

  DISTRO                    :  apache

  AUTO ELASTIC              :  N/A

  MIN COMPUTE NODES NUM     :  N/A

  MAX COMPUTE NODES NUM     :  N/A

  IO SHARES                 :  NORMAL

  STATUS                    :  RUNNING

 

  GROUP NAME  ROLES                                    INSTANCE  CPU  MEM(MB)  TYPE    SIZE(GB)

  ---------------------------------------------------------------------------------------------

  master      [hadoop_namenode, hadoop_jobtracker]     1         2    7500     SHARED  50

  worker      [hadoop_datanode, hadoop_tasktracker]    3         1    3748     LOCAL   50

  client      [hadoop_client, pig, hive, hive_server]  1         1    3748     SHARED  50

 

  ============================================================================

 

もう少し詳細な、Hadoop クラスタとノードの構成情報を表示してみました。

マスタノードでは、vSphere HA が有効です。("haFlag" : "on")

serengeti>cluster export --name hdp_cluster03

{

  "nodeGroups" : [

    {

      "name" : "master",

      "roles" : [

        "hadoop_namenode",

        "hadoop_jobtracker"

      ],

      "instanceNum" : 1,

      "instanceType" : "MEDIUM",

      "storage" : {

        "type" : "shared",

        "sizeGB" : 50

      },

      "cpuNum" : 2,

      "memCapacityMB" : 7500,

      "swapRatio" : 1.0,

      "haFlag" : "on",

      "configuration" : {

      }

    },

    {

      "name" : "worker",

      "roles" : [

        "hadoop_datanode",

        "hadoop_tasktracker"

      ],

      "instanceNum" : 3,

      "instanceType" : "SMALL",

      "storage" : {

        "type" : "local",

        "sizeGB" : 50

      },

      "cpuNum" : 1,

      "memCapacityMB" : 3748,

      "swapRatio" : 1.0,

      "haFlag" : "off",

      "configuration" : {

      }

    },

    {

      "name" : "client",

      "roles" : [

        "hadoop_client",

        "pig",

        "hive",

        "hive_server"

      ],

      "instanceNum" : 1,

      "instanceType" : "SMALL",

      "storage" : {

        "type" : "shared",

        "sizeGB" : 50

      },

      "cpuNum" : 1,

      "memCapacityMB" : 3748,

      "swapRatio" : 1.0,

      "haFlag" : "off",

      "configuration" : {

      }

    }

  ],

  "configuration" : {

  },

  "networkNames" : [ ]

}

 

今回は、create コマンドにパスワードを指定していないので、

Hadoop ノードの OS にログインするためのパスワードは自動生成されます。

 

自動生成されたパスワードは VM のコンソール画面に表示されるので・・・

bde-cli-cluster-create-02.png

 

ノードのゲスト OS にアクセスする場合は

いったん serengeti ユーザで SSH ログインして変更します。

これは面倒なので、パスワードは Hadoop クラスタ構築時に指定しておいた方がよさそうです。

[serengeti@192 ~]$ sudo /opt/serengeti/sbin/set-password -u

New password:  ★パスワードを入力する。

Retype password:

 

特にトポロジ指定していないので、

Hadoop ノードの topology.data は空ファイルになっています。

[serengeti@192 ~]$ cat /etc/hadoop/conf/topology.data

    ★何も記載なし。

[serengeti@192 ~]$ ls -l /etc/hadoop/conf/topology.data

-rw-r--r-- 1 root root 1 Oct  4 07:10 /etc/hadoop/conf/topology.data

 

 

今回の話は、マニュアルではこのあたりです。

VMware vSphere Big Data Extensions Command-Line Interface Guide

  > Creating Hadoop and HBase Clusters

Serengeti’s Default Hadoop Cluster Configuration

 

BDE については、こちらもどうぞ・・・

vSphere で Hadoop してみる。(Big Data Extentions) 第1回

vSphere BDE(Hadoop)と vSphere HA の関係について。

vSphere BDE の Hadoop 的なデータストア活用について。(Local / Shared)

vShere BDE の Hadoop 的なトポロジ認識について。(Rack awareness と HVE)

 

以上、Serengeti CLI で Hadoop クラスタを作成してみる話でした。

今回は、このポストの続きです。

vShere BDE の Hadoop 的なトポロジ認識について。(Rack awareness と HVE)

 

VMware vSphere Big Data Extensions(BDE)の

トポロジ 認識の設定をしてみます。

Hadoop Virtualization Extensions(HVE)も設定してみます。

 

BDE をセットアップした直後の

Hadoop クラスタ作成(Create New Big Data Cluster)画面では、

NONE と HOST_AS_RACK のみが選択できます。

そして使用する Hadoop ディストリビューションで HVE が有効で、

BDE に topology 認識させるためのファイルをアップロードしておくと

RACK_AS_RACK  と HVE も指定できるようになります。

bde-topology-conig-01.png


BDE にトポロジ情報を登録する


BDE 2.0 にデフォルトで含まれるディストリビューションでも、

apache(Apache Hadoop 1.2)は HVE に対応していて、

BDE でも有効化(HVE = true)されています。

serengeti>distro list

  NAME    VENDOR  VERSION  HVE    ROLES                                                                                                                                                                                      

  ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

  apache  Apache  1.2.1    true   [hadoop_client, hadoop_datanode, hadoop_jobtracker, hadoop_namenode, hadoop_tasktracker, hbase_client, hbase_master, hbase_regionserver, hive, hive_server, pig, zookeeper]                

  bigtop  BIGTOP  0.7.0    false  [hadoop_client, hadoop_datanode, hadoop_journalnode, hadoop_namenode, hadoop_nodemanager, hadoop_resourcemanager, hbase_client, hbase_master, hbase_regionserver, hive, hive_server, pig, zookeeper]

 

そこで、BDE の管理サーバに serengeti CLI を使用して

ラックと ESXi のマッピングファイルをアップロードすると・・・

serengeti>topology list

serengeti>       ★まだ BDE にはトポロジ登録されていない。

serengeti>! cat /home/serengeti/rack_esxi_map.txt

command is:cat /home/serengeti/rack_esxi_map.txt

rack01: hv55n1.vmad.local,hv55n2.vmad.local

rack02: hv55n3.vmad.local,hv55n4.vmad.local

serengeti>

serengeti>topology upload --fileName /home/serengeti/rack_esxi_map.txt

topology uploaded  ★BDE にトポロジ登録した。

serengeti>topology list

  RACK    HOSTS

  ----------------------------------------------

  rack01  [hv55n1.vmad.local, hv55n2.vmad.local]

  rack02  [hv55n3.vmad.local, hv55n4.vmad.local]

 

serengeti>

 

RACK_AS_RACK と HVE も topology として選択できるようになります。

bde-topology-conig-02.png

 

それぞれのトポロジについては、

マニュアルではこのあたりを参照してください。

VMware vSphere Big Data Extensions Administrator's and User's Guide

  > Creating Hadoop and HBase Clusters

About Cluster Topology

http://pubs.vmware.com/bde-2/index.jsp#com.vmware.bigdataextensions.admin.doc/GUID-C2A2E573-5BD7-4BEC-9F72-5F161A8BDFC6.html

 


BDE トポロジ指定と、Hadoop のトポロジ情報ファイル生成

 

まず、下記のように HOST_AS_RACK を選択した場合に

Hadoop ノードに作成されるトポロジ情報のファイルを見てみます。

bde-topology-conig-03.png

 

トポロジ情報のファイルは、下記のようにHadoop ノードそれぞれに作成されます。

Hadoop ノードの VM(IP アドレス)が、「/<ESXi>」に紐付けられています。

[root@192 ~]# cat /etc/hadoop/conf/topology.data

192.168.5.123 /hv55n3.vmad.local

192.168.5.130 /hv55n3.vmad.local

192.168.5.129 /hv55n4.vmad.local

192.168.5.120 /hv55n1.vmad.local

192.168.5.121 /hv55n2.vmad.local

192.168.5.122 /hv55n4.vmad.local

 

このファイルは、下記のスクリプトでのトポロジ判断に使われるようです。

[root@192 ~]# cat /etc/hadoop/conf/topology.sh

#!/bin/bash

 

# this script is copied from http://wiki.apache.org/hadoop/topology_rack_awareness_scripts

 

HADOOP_CONF=/etc/hadoop/conf

 

while [ $# -gt 0 ] ; do

  nodeArg=$1

  exec< ${HADOOP_CONF}/topology.data

  result=""

  while read line ; do

    ar=( $line )

    if [ "${ar[0]}" = "$nodeArg" ] ; then

      result="${ar[1]}"

    fi

  done

  shift

  if [ -z "$result" ] ; then

    echo -n "/default-rack "

  else

    echo -n "$result "

  fi

done

 

たとえば、下記のような感じです。

[root@192 ~]# bash /etc/hadoop/conf/topology.sh 192.168.5.123

/hv55n3.vmad.local [root@192 ~]#

 

次に、下記のように RACK_AS_RACK を選択した場合を見てみます。

bde-topology-conig-04.png

 

トポロジ情報のファイルでは、

Hadoop ノードの VM(IP アドレス)が、

「/<BDE の topology で定義したラック名>」に紐付けられています。

[root@192 ~]# cat /etc/hadoop/conf/topology.data

192.168.5.133 /rack01

192.168.5.131 /rack02

192.168.5.136 /rack02

192.168.5.132 /rack01

192.168.5.135 /rack02

192.168.5.134 /rack02

 

この場合は、下記のようにトポロジが判断されるのでしょう。

[root@192 ~]# bash /etc/hadoop/conf/topology.sh 192.168.5.133

/rack01 [root@192 ~]#

 

最後に、下記のように RACK_AS_RACK を選択した場合を見てみます。

bde-topology-conig-05.png

 

トポロジ情報のファイルでは、

Hadoop ノードの VM(IP アドレス)が、

「/<BDE の topology で定義したラック名>/<ESXi>」に紐付けられています。

[root@192 ~]# cat /etc/hadoop/conf/topology.data

192.168.5.122 /rack01/hv55n1.vmad.local

192.168.5.127 /rack02/hv55n3.vmad.local

192.168.5.125 /rack02/hv55n4.vmad.local

192.168.5.121 /rack01/hv55n1.vmad.local

192.168.5.124 /rack02/hv55n3.vmad.local

192.168.5.126 /rack01/hv55n2.vmad.local

192.168.5.123 /rack02/hv55n4.vmad.local

192.168.5.120 /rack01/hv55n2.vmad.local

 

この場合は、下記のようにトポロジが判断されるのでしょう。

[root@192 ~]# bash /etc/hadoop/conf/topology.sh 192.168.5.122

/rack01/hv55n1.vmad.local [root@192 ~]#

 

ちなみに、

BDE で構成した Hadoop ノードの設定ファイル(core-site.xml)には

HVE を有効化する設定も含まれていました。

[root@192 ~]# cat /etc/hadoop/conf/core-site.xml

<?xml version="1.0"?>

<?xml-stylesheet type="text/xsl" href="configuration.xsl"?>

<!-- check for all settings at http://hadoop.apache.org/common/docs/stable/core-default.html -->

<configuration>

<property>

  <name>fs.default.name</name>

  <value>hdfs://192.168.5.122:8020</value>

</property>

 

<!-- turn on Hadoop Rack Awareness -->

<property>

  <name>topology.script.file.name</name>

  <value>/etc/hadoop/conf/topology.sh</value>

  <description>Topology scripts are used by hadoop to determine the rack location of nodes. This information is used by hadoop to replicate block data to redundant racks.</description>

</property>

 

<!-- settings for Hadoop Virtualization Extensions -->  ★このあたりから

<property>

  <name>net.topology.nodegroup.aware</name>

  <value>true</value>

  <description>By default, network topology is not aware of nodegroup layer.</description>

</property>

<property>

  <name>net.topology.impl</name>

  <value>org.apache.hadoop.net.NetworkTopologyWithNodeGroup</value>

  <description>The default implementation of NetworkTopology which is classic three layer one.</description>

</property>

<property>

  <name>dfs.block.replicator.classname</name>

  <value>org.apache.hadoop.hdfs.server.namenode.BlockPlacementPolicyWithNodeGroup</value>

  <description>The default implementation of BlockPlacementPolicy.</description>

</property>

 

<!-- properties specified by users -->

<!-- end -->

 

 

</configuration>

 

BDE については、こちらもどうぞ・・・

vSphere で Hadoop してみる。(Big Data Extentions) 第1回

vSphere BDE(Hadoop)と vSphere HA の関係について。

vSphere BDE の Hadoop 的なデータストア活用について。(Local / Shared)

 

以上、BDE のトポロジ認識についてでした。