Quantcast
Channel: VMware Communities : Blog List - All Communities
Viewing all 3135 articles
Browse latest View live

Converting problems with VMWare Converter Standalone 5.5 Error 14 opening disk, OpenDisks failed, mntapi error: 226 - The specified virtual disk needs repair

$
0
0

I am migration from VMWorkstation 6.5.1 to ESXi 5.5. Workstation runs under Win XP SP3. There are two VM's to be converted. The first one is an XP SP3 Engine used for Kerio Mailserver (of course, it will me migrated to a newer OS - but as usual there are issues migration Kerio Connect from XP to CentOS - so we need to stay a bit longer with the running system).

The second VM is a MS Server 2008 driving a MS SQL Server.

 

The conversion of the XP VM was done without any issues. But with the MS Server VM conversion is failing again and again. It fails before entering to ESXi Host IP-Address.

 

Situation:

VMWare Converter Standalone runs on a Windows 7 System, SP1, 12GB Ram. The MS Server VM have been copied to the local disk. The VM has two virtual disks (SCSI) in separated folders  and is running fine with the VMWorkstation (no log entries found, that there is already something worse).

After several failures I decided to copy everything into one folder and change the vmx conf file (for the second virtual disk I removed only the path, the first one did not have any path in the setup).

Coming from the converter log files, my first guess was that there is not enough space on C on the Windows 7 System left.

 

First solution:


 

Result:

 

  • VDDK tool couldn't repair the disk

 

Second Solution:

 

  • Starting the VM with VMWorkstation 10 did work
  • In the VM (Windows 2008 Server) execute "checkdisk" for all disks (may need several restarts of the VM)
  • Close VMWorkstation
  • Now converting with VMConverter works.

 

2014-09-10T21:05:52.681+02:00 [01228 warning 'Locale'] Duplicate key 'hi_IN' in file 'D:\Program Files (x86)\VMware\VMware vCenter Converter Standalone\locale\iso2win.vlcl', only first one is used

[...}

2014-09-10T21:37:22.943+02:00 [04412 warning 'Locale'] Resource module 'logic' not found for locale 'de', using from default locale...

2014-09-10T21:37:22.943+02:00 [04412 warning 'Locale'] Resource module 'logic' not found in default locale either. Using from English locale...

[...]

2014-09-10T21:37:39.652+02:00 [04412 error 'wizardController'] Cannot query source HW info: vmodl.fault.SystemError

2014-09-10T21:37:42.665+02:00 [02852 error 'wizardController'] Cannot query source HW info: vmodl.fault.SystemError

2014-09-10T21:49:44.064+02:00 [04860 error 'Default'] SourceSelectPluginModel::BuildFilter 3rd party type microsoftVirtualPCVM not found

2014-09-10T21:49:44.064+02:00 [04860 error 'Default'] SourceSelectPluginModel::BuildFilter 3rd party type parallelsVM not found

2014-09-10T21:49:44.064+02:00 [04860 error 'Default'] SourceSelectPluginModel::BuildFilter 3rd party type vmwareVCBBackup not found

2014-09-10T21:49:44.064+02:00 [04860 error 'Default'] SourceSelectPluginModel::BuildFilter 3rd party type livestateBackup not found

2014-09-10T21:49:44.064+02:00 [04860 error 'Default'] SourceSelectPluginModel::BuildFilter 3rd party type shadowProtectBackup not found

2014-09-10T21:49:44.064+02:00 [04860 error 'Default'] SourceSelectPluginModel::BuildFilter 3rd party type acronisBackup not found

2014-09-10T21:49:44.064+02:00 [04860 error 'Default'] SourceSelectPluginModel::BuildFilter 3rd party type vmwareVM not found

2014-09-10T21:49:44.064+02:00 [04860 error 'Default'] SourceSelectPluginModel::BuildThirdpartyHostedExtVector 3rd party type vmwareVM not found

[...]

2014-09-10T21:37:07.102+02:00 [01540 error 'Ufa.HTTPService'] Failed to read request; stream: <io_obj p:0x0135b604, h:-1, <pipe '\\.\pipe\vmware-converter-server-soap'>, <pipe '\\.\pipe\vmware-converter-server-soap'>>, error: class Vmacore::TimeoutException(Operation timed out)

2014-09-10T21:49:43.253+02:00 [00968 error 'Ufa.HTTPService'] Failed to read request; stream: <io_obj p:0x0139c39c, h:-1, <pipe '\\.\pipe\vmware-converter-server-soap'>, <pipe '\\.\pipe\vmware-converter-server-soap'>>, error: class Vmacore::TimeoutException(Operation timed out)


And from the worker log the conversion ends with this:

 

2014-09-10T21:37:22.936+02:00 [01416 info 'Default'] Sysimgbase_DiskLib_OpenWithPassPhrase failed with 'The specified virtual disk needs repair' (error code:14)

2014-09-10T21:37:22.936+02:00 [01416 info 'Default'] Error 14 opening disk D:\test\mssqlserver_c\Boot Windows Server 2008.vmdk.

2014-09-10T21:37:22.936+02:00 [01416 warning 'Default'] ERROR 14 opening disk D:\test\mssqlserver_c\Boot Windows Server 2008.vmdk.

2014-09-10T21:37:22.936+02:00 [01416 error 'Default'] [BaseDiskSetComputer::DoOpen] OpenDisks failed, mntapi error: 226

2014-09-10T21:37:22.936+02:00 [01416 error 'Default'] [BaseDiskSetComputer::AnalyzeErrorAndThrow] Error occurred when opening disk set, MNTAPI_ERROR = 226 MNTAPI errorType = 2, errorCode = 14

2014-09-10T21:37:22.936+02:00 [01416 info 'Default'] Scheduled timer canceled, StopKeepAlive succeeds

2014-09-10T21:37:22.936+02:00 [01416 error 'Default'] Unknown exception while invoking VMOMI method queryComputerInfo

2014-09-10T21:37:39.580+02:00 [01428 info 'Default'] Source path [D:\test\mssqlserver_c\Windows Server 2008.vmx] is mapped to [D:\test\mssqlserver_c\Windows Server 2008.vmx]

2014-09-10T21:37:39.580+02:00 [01428 info 'Default'] Source path [D:\test\mssqlserver_c\Windows Server 2008.vmx] is mapped to [D:\test\mssqlserver_c\Windows Server 2008.vmx]

2014-09-10T21:37:39.580+02:00 [01428 info 'Default'] Source path [D:\test\mssqlserver_c\Windows Server 2008.vmx] is mapped to [D:\test\mssqlserver_c\Windows Server 2008.vmx]

2014-09-10T21:37:39.580+02:00 [01428 info 'Default'] Creating vmx file parser

2014-09-10T21:37:39.580+02:00 [01428 info 'Default'] [BaseParserImpl::Parse] Config info is not cached

2014-09-10T21:37:39.580+02:00 [01428 info 'Default'] Parsing D:\test\mssqlserver_c\Windows Server 2008.vmx

2014-09-10T21:37:39.651+02:00 [01428 info 'Default'] Sysimgbase_DiskLib_OpenWithPassPhrase failed with 'The specified virtual disk needs repair' (error code:14)

2014-09-10T21:37:39.651+02:00 [01428 info 'Default'] Error 14 opening disk D:\test\mssqlserver_c\Boot Windows Server 2008.vmdk.

2014-09-10T21:37:39.651+02:00 [01428 warning 'Default'] ERROR 14 opening disk D:\test\mssqlserver_c\Boot Windows Server 2008.vmdk.

2014-09-10T21:37:39.651+02:00 [01428 error 'Default'] [BaseDiskSetComputer::DoOpen] OpenDisks failed, mntapi error: 226

2014-09-10T21:37:39.651+02:00 [01428 error 'Default'] [BaseDiskSetComputer::AnalyzeErrorAndThrow] Error occurred when opening disk set, MNTAPI_ERROR = 226 MNTAPI errorType = 2, errorCode = 14

2014-09-10T21:37:39.652+02:00 [01428 info 'Default'] Scheduled timer canceled, StopKeepAlive succeeds

2014-09-10T21:37:39.652+02:00 [01428 error 'Default'] Unknown exception while invoking VMOMI method queryComputerInfo

2014-09-10T21:37:42.595+02:00 [01428 info 'Default'] Source path [D:\test\mssqlserver_c\Windows Server 2008.vmx] is mapped to [D:\test\mssqlserver_c\Windows Server 2008.vmx]

2014-09-10T21:37:42.595+02:00 [01428 info 'Default'] Source path [D:\test\mssqlserver_c\Windows Server 2008.vmx] is mapped to [D:\test\mssqlserver_c\Windows Server 2008.vmx]

2014-09-10T21:37:42.595+02:00 [01428 info 'Default'] Source path [D:\test\mssqlserver_c\Windows Server 2008.vmx] is mapped to [D:\test\mssqlserver_c\Windows Server 2008.vmx]

2014-09-10T21:37:42.595+02:00 [01428 info 'Default'] Creating vmx file parser

2014-09-10T21:37:42.595+02:00 [01428 info 'Default'] [BaseParserImpl::Parse] Config info is not cached

2014-09-10T21:37:42.595+02:00 [01428 info 'Default'] Parsing D:\test\mssqlserver_c\Windows Server 2008.vmx

2014-09-10T21:37:42.664+02:00 [01428 info 'Default'] Sysimgbase_DiskLib_OpenWithPassPhrase failed with 'The specified virtual disk needs repair' (error code:14)

2014-09-10T21:37:42.664+02:00 [01428 info 'Default'] Error 14 opening disk D:\test\mssqlserver_c\Boot Windows Server 2008.vmdk.

2014-09-10T21:37:42.664+02:00 [01428 warning 'Default'] ERROR 14 opening disk D:\test\mssqlserver_c\Boot Windows Server 2008.vmdk.

2014-09-10T21:37:42.664+02:00 [01428 error 'Default'] [BaseDiskSetComputer::DoOpen] OpenDisks failed, mntapi error: 226

2014-09-10T21:37:42.664+02:00 [01428 error 'Default'] [BaseDiskSetComputer::AnalyzeErrorAndThrow] Error occurred when opening disk set, MNTAPI_ERROR = 226 MNTAPI errorType = 2, errorCode = 14

2014-09-10T21:37:42.664+02:00 [01428 info 'Default'] Scheduled timer canceled, StopKeepAlive succeeds

2014-09-10T21:37:42.664+02:00 [01428 error 'Default'] Unknown exception while invoking VMOMI method queryComputerInfo

2014-09-10T21:44:43.346+02:00 [01428 info 'Default'] Source path [D:\test\mssqlserver_c\Windows Server 2008.vmx] is mapped to [D:\test\mssqlserver_c\Windows Server 2008.vmx]

2014-09-10T21:44:43.346+02:00 [01428 info 'Default'] Source path [D:\test\mssqlserver_c\Windows Server 2008.vmx] is mapped to [D:\test\mssqlserver_c\Windows Server 2008.vmx]

2014-09-10T21:44:43.346+02:00 [01428 info 'Default'] Source path [D:\test\mssqlserver_c\Windows Server 2008.vmx] is mapped to [D:\test\mssqlserver_c\Windows Server 2008.vmx]

2014-09-10T21:44:43.346+02:00 [01428 info 'Default'] Creating vmx file parser

thx

https://communities.vmware.com/message/2430033#2430033


vCenter Upgradation from 5.0.1 to 5.5

$
0
0

I was think for upgrading my VMware environment to latest version, Hence after looking at different sites. I gather many different views/procedure and finally consolidated my own procedure to upgrade my VMware infrastructure. Kindly find the attached procedure for upgrading vCenter from 5.0.1 to 5.5.

 

Thanks

Umesh Ahuja

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

$
0
0

Hadoop では、分散処理のマスタとなるノード(サーバ)の

冗長化が課題となることがあると思います。


たとえば下記のあたりの障害対策をどうするかが、よく話題になっています。

  • HDFS のマスタノード(NameNode)
  • MapReduce のマスタノード(JobTrackser)

 

vSphere Big Data Extensions(BDE) と

vSphere での冗長化については、

マニュアルだと下記のあたりにそれとなく記載があります。

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

  > Managing Hadoop and HBase Clusters

About vSphere High Availability and vSphere Fault Tolerance

http://pubs.vmware.com/bde-2/topic/com.vmware.bigdataextensions.admin.doc/GUID-C69A72A1-93B8-4EB9-A2B2-16E1FCAC108D.html

 

FT では当然、保護可能だと思います。

ただし FT は vSphere 5.5 までだと 1vCPU しか割り当てられないので

実際のところは vSphere HA が有効そうな気がします。


そして、vSphere HA については

マスタノードのプロセス検知まで対応しているのか気になったので試してみました。

 

BDE で自動構築した VM の HA 保護構成について


BDE で自動構築(テンプレートからクローン)された VM のうち、

マスタノードになるものは、デフォルトで

共有データストア(Shared datastores)に配置されます。


DataMaster が、HDFS の NameNode で、

ComputeMaster が、MapReduce の JobTracker です。

bde-vha-02.png

 

vSphere HA での VM の保護設定を確認してみると、

マスタノードは HA が有効で、それ以外は無効になっていました。

※仮想マシンの監視は「仮想マシンとアプリケーションの監視」にしてあります。

bde-vha-03.png

 

マスタノードの確認

 

ためしにマスタノード障害を発生させてみるために、

マスタノードを確認します。

BDE では、BDE の Web Client プラグイン画面から、マスタノードがわかります。

それぞれゲスト OS の、IP アドレスがわかります。

bde-vha-01.png

 

他にも、BDE の管理サーバに 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>cluster target --name hdp_cluster01

serengeti>cfg info

Hadoop [1.2.1 rev.1503152][fs=hdfs://192.168.5.128:8020][jt=192.168.5.125:8021]

「fs=~」が HDFS のマスタノード(NameNode)、

「jt=~」が MapReduce のマスタノード(JobTracker)です。

 

 

マスタノードを停止してみる。

 

まず、HDFS のマスタノードを停止してみます。

hdp_cluster01-DataMaster-0 に SSH でログインして

NameNode プロセスを停止してみました。

[root@192 ~]# uname -n

192.168.5.128  ★ホスト名は IP アドレスと同じになっている。

[root@192 ~]# jps

4930 NameNodeMonitor

25430 Jps

2680 NameNode

 

kill コマンドで、プロセス停止してみました。

[root@192 ~]# kill 2680

[root@192 ~]# jps

4930 NameNodeMonitor

25466 Jps

 

少し待つと、vSphere HA が作動します。

bde-vha-04.png

 

プロセスの再起動ではなく、

VM がリセットされ、ゲスト OS があらためて起動されます。

bde-vha-05.png

 

VM が vSphere HA でリセットされたことが

イベント にも残っています。

bde-vha-06.png

 

ゲスト OS 起動後は、

NameNode のプロセスが自動起動します。

[root@192 ~]# uname -n

192.168.5.128

[root@192 ~]# uptime

13:45:38 up 6 min,  1 user,  load average: 0.10, 0.45, 0.29

[root@192 ~]# jps

2716 NameNodeMonitor

2309 NameNode

2830 Jps

 

同様に、MapResuce の JobTracker のプロセスを停止してみました。

hdp_cluster01-ComputeMaster-0 に SSH でログインして、

JobTracker のプロセスを停止してみます。

[root@192 ~]# uname -n

192.168.5.125  ★ホスト名は IP アドレスと同じになっている。

[root@192 ~]# jps

2656 JobTracker

15403 Jps

2802 JobTrackerMonitor

[root@192 ~]# kill 2656

[root@192 ~]# jps

15418 Jps

2802 JobTrackerMonitor

 

しばらくすると、JobTracker の VM も

vSphere HA によってリセットされました。

VM がリセットされることで、

ゲスト OS の起動に合わせて JobTracker のプロセスが起動(復旧)されます。

bde-vha-07.png

 

vSphere HA では、ESXi ホスト障害や、VM(ゲスト OS)のハングといった

障害は標準で検知でき、自動復旧できます。

アプリケーション障害を検知する場合には

そのアプリケーション側で vSphere HA に対応している必要があるのですが、

BDE で自動構築した Apache Haoop のマスタノードは

NameNode も、JobTracker も vSphere HA のアプリケーション監視に

対応しているようです。

 

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

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

 

以上、BDE と vSphere HA についてでした。

Print server Resource Issue

$
0
0

Hello

 

Hi everybody i have issue with  Our Print server has using high CPU resource ( 4 cpu and 16GB memory). Print spooler.exe and papercut application  always using more resource, Please anybody have idea... to solve this issue. 

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

$
0
0

Hadoop では、ローカルディスクを活用をすることで知られています。

一方、サーバ仮想化環境は共有ディスクを使用することが一般的なので

Hadoop とサーバ仮想化はあまり相性がよくないといわれることがあります。


というわけで、

BDE はどのようにデータストア(ローカル / 共有ディスク)を使用するのか見てみました。

 

BDE でのデータストア利用イメージ


BDE にデフォルトで含まれている

Apache Hadoop 1.2 で、Basic Hadoop Cluster を作成した場合を

例にすると、だいたい下記のような感じです。

BDE-Hadoop-ds-01.png


Hadoop でマスタノードと呼ばれるものは

一般的に、そこまでデータの I/O が無いとされていますが

そのかわり耐障害性が求められます。

今回の例では、下記がマスタノードにあたります。

  • HDFS の NameNode(NN)
  • MapReduce の JobTracker(JT)


一方スレーブノードは、

大量のデータを格納していて

それをもとに分散処理を実行したりするので

ローカルディスクを活用したいサーバです。

今回の例では、下記がマスタノードにあたります。

  • HDFS の DataNode(DN)
  • MapReduce の TaskTracker(TT)


BDE では、ノードの役割によって

ローカルデータストアと共有データストアを使い分けていて、

だいたい下記のような役割分担です。

  • マスタノード → ESXi のローカルデータストアを使用する。
  • スレーブノード → 共有データストアを利用する。

 

マスタノードは、共有データストアに

仮想マシン(VMDK ファイル)が配置されているため、

vMotion や、vSphere HA といった仮想化環境特有の

高可用性の機能を利用できるようになっています。

もうすぐ vSphere FT が複数 vCPU 対応になるようなので

そうなったらさらに有益かと思いました・・・

 

スレーブノードは、ローカルディスクを使用しますが、

もともと MapReduce / HDFS で冗長化が考慮されているので

ノード障害が発生してもそうに問題にならないという想定でしょう。

 

BDE でのデータストアの指定


BDE ではローカルデータストアと共有データストアを使い分けますが、

そのためにvSphere 環境で利用しているデータストアを

さらに BDE で使用するデータストアとしてリソース登録します。

BDE-Hadoop-ds-02.png

 

BDE で Hadoop クラスタを作成するまえにリソース登録しておき、

Hadoop クラスタ作成時には

ノードグループごとにデータストアの種類(Local / Shared)だけ指定します。

 

BDE Web Client プラグイン画面での見え方。


ローカルデータストアを、BDE に登録する例です。

Local / Shared データストアは、それぞれ

まとめて1つのリソースとして登録することができます。

bde-ds-01.png

 

下記の例では、1つの BDE データストア リソースとして

4つのデータストア(VC Datastores)を登録しています。

bde-ds-02.png


逆に、VC データストアそれぞれを

1つずつ BDE データストア リソースとして登録することもできます。

bde-ds-03.png

 

その場合は、下記のようになります。

bde-ds-04.png


Hadoop のノードのデータストアの種類は

Hadoop クラスタの作成(Create New Big Data Cluster)の時に

選択することができます。デフォルトでは、

マスタノード(~Master Node Group)は共有データストア(Shared datastore)、

スレーブノード(Worker Node Group)はローカルデータストア(Local datastores)

になっています。

bde-ds-05.png

 

Resource template で「Customize」を選択すると

データストアを変更することができますが、データストア名を指定するわけではなく

「Local」もしくは「Shared」を指定することで

あとは BDE によって自動的にデータストアが選択されます。

bde-ds-06.png

 

設定はポリシーベースっぽい感じです。

 

マニュアルでは下記のあたり・・・

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

Big Data Extensions: Add a Datastore

Create a Hadoop or HBase Cluster in the vSphere Web Client

 

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

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

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

 

以上、BDE とデータストアの話でした。

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

$
0
0

今回は、VMware vSphere Big Data Extensions(BDE) の

Hadoop 的なネットワークトポロジ 認識についての話です。


Hadoop には処理を効率化するためにネットワーク トポロジ(構成)を認識する仕組みがあります。

これは ラック ウェアネス などと呼ばれていて、

分散処理中の大量データ転送を避けるための考慮をしたりデータローカリティ)

HDFS でデータレプリカ配置をうまく分散して

ノード障害時の可用性向上、データ消失防止したりするために重要です。


トポロジ認識は、サーバ(Hadoop のノード)とサーバラックを

紐づけるマッピングファイルを用意することで実現しています。

たとえば、下記のようにサーバとラックの対応を定義して Hadoop にトポロジを伝えます。

# cat topology.data

hadoop-node1.vmad.local  /datacenter01/rack01

hadoop-node2.vmad.local  /datacenter01/rack02

 

BDE では Hadoop クラスタの自動構築時に、このマッピングファイルを自動生成できます。

さらに VMware による、サーバ仮想化レイヤを考慮できるようになる

Hadoop Virtualization Extensions(HVE)という機能拡張も利用することができます。

Hadoop Virtualization Extensions on VMware vSphere 5

http://www.vmware.com/files/pdf/Hadoop-Virtualization-Extensions-on-VMware-vSphere-5.pdf

 

Hadoop Common / HADOOP-8468

Umbrella of enhancements to support different failure and locality topologies

https://issues.apache.org/jira/browse/HADOOP-8468

 

トポロジ認識は、BDE で Hadoop クラスタを作成するときに

4種類の認識方法から選択できます。

  • NONE
    トポロジを気にしない。
  • HOST_AS_RACK
    ゲスト OS を Hadoop のノード、ESXi を Hadoop でのラックとして扱う。
  • RACK_AS_RACK
    ゲスト OS を Hadoop のノード、マッピングファイルでのラック を Hadoop でのラックとして扱う。
  • HVE
    ゲスト OS、ESXi、ラックそれぞれを認識する。
    ※ただし、Hadoop ディストリビューションでも HVE 対応が必要。

 

BDE では、デフォルトで上記のうち NONE と HOST_AS_RACK だけが選択でき、

BDE 管理サーバ(Serengeti)にラックと ESXi のマッピングを定義するファイル

(上の方で例とした topology.data ファイルとは別のもの)をアップロードすることで

RACK_AS_RACK と HVE が選択できるようになります。

 

たとえば、下記のようなマッピングファイルになります。

# cat /home/serengeti/rack_esxi_map.txt

rack01: esxi01.vmad.local,esxi02.vmad.local

rack02: esxi03.vmad.local,esxi04.vmad.local

 

BDE では HVE を使用しない場合、

BDE に は、物理ラックか、ESXi どちらかを

Hadoop のラックとして認識させることになります。

bde-topology -01.png


このとき Hadoop のラック認識として、

ESXi を選ぶと物理ラックが境界として認識できず、

物理ラックを選ぶと ESXi が境界として認識できなくなってしまいます。

※下の図だと、オレンジ点線の部分が Hadoop から認識できなくなってしまいます。

bde-topology -02.png


そして、境界が下記の赤枠のように認識されるので、

うまくラック内にデータ転送を収めたりできなくなったり(HOST_AS_RACK)

同一 ESXi で稼働する VM 同士でデータの複製を持ったり(RACK_AS_RACK)

することが起こりえます。

bde-topology -03.png

 

そこで、HVE を使用することで

VM、ESXi、物理ラック それぞれを意識した

トポロジ 構成のマッピングファイルを自動生成できるようになります。

BDE のホワイトペーパーなどでは、ESXi は「Node Group」という概念で説明されています。

bde-topology -04.png

 

というわけで、Hadoop ディストリビューションが HVE が対応しているのであれば

HVE にしておくのがよいと思います。結構、HVE 対応しているようです。

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

  > Managing Hadoop Distributions

Hadoop Distribution Deployment Types

 

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

つづく・・・

vShere BDE の Hadoop 的なトポロジ認識について。その2(HVE Topology 設定編)

vShere BDE の Hadoop 的なトポロジ認識について。その2(HVE Topology 設定編)

$
0
0

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

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 のトポロジ認識についてでした。

VMware VVols: It’s time to revisit the SAN and NAS debate

$
0
0

(this post originally appeared at The Virtual Storage Guy)

 

Which is better with VMware, SAN or NAS storage? This simple question sparked numerous debates throughout the IT industry during the formative and hyper-growth years of VMware. The conversation spanned performance concerns, dove into operational trade-offs and more importantly defined a new set of capabilities and requirements which have led us to VVols. For me this was a magical time, one that with the perspective clearly shows how unprepared we all were for the conversation, adoption disruption and innovation that resulted. As with every topic, time has removed the conversation from the limelight; however, with the upcoming release of VMware VVols the time seems right to revisit the SAN versus NAS debate.

 

Are you ready for round two?


The perspective of an insider

 

Before we dive into the SAN and NAS with VVols, I think it beneficial to ensure we are on the same page. I'd like to offer the following definitions for our discussion.


SAN: SCSI based, block storage protocols used with VMware in the form of VMFS datastores and as VM-direct accessed RDMs. Protocols include: Fibre Channel (FC), iSCSI & Fibre Channel over Ethernet (FCoE).


NAS: File access storage protocols used with VMware in the form of NFS datastores and VM-direct accessed LINUX mount points & Windows file shares. Protocols include: Network File System (NFS) and Server Message Block (SMB and formerly known as the Common Internet File System or CIFS).


I classify the SAN vs NAS debate into three eras…


2006 – 2010: VMware releases VI3 and introduces Ethernet storage options NFS & iSCSI to the existing support for Fibre Channel (FC).

At the time most viewed FC as enterprise class, iSCSI as a new low-cost alternative and frankly ignored NFS. What we as an industry learned at that time was network file systems were performant, more capable and ideal for managing tens to thousands of VMs as compared to clustered file systems. NFS provided VM-granular functionality and was devoid of challenges found in areas like shallow per-LUN IO queues, SCSI reservation contention and file locking overheads.

During this era the edge clearly goes to NFS and originates what will eventually become the VVols initiative and is the core for many new storage platforms including Tintri, Nutanix and Simplivity.


2010 – 2014: VMware releases vSphere 4.1 and vStorage APIs for Array Integration (VAAI).

The masses fawn over ‘Full Copy’ the copy offload mechanism but the largest benefit was found in the SCSI Atomic Test and Set (ATS) API, which replaced SCSI reservations and in turn reduced the volume of metadata and optimistic locks. During this time many SAN vendors introduced large I/O queues on their target adapters providing a dynamic pool of I/O to be available per datastore. Together these enhancements removed the many hidden I/O bottlenecks that frustrated and limited the scale of many SAN deployments.

During this time we see ‘protocol parity’ emerge – while SAN and NAS became peers in terms of I/O scaling, trade-offs and advantages still existed. NAS environments were still simpler to manage and saw integrations at higher levels of the VMware stack (i.e. View and vCloud Director). By contrast SAN supported more applications and application deployment models while also appearing to receive greater engineering investments from VMware. In summary, VAAI quieted much of the SAN versus NAS debate.


2014 – on...: VMware releases the beta of VVols and GA is likely within a year.

The architecture provides functional parity for SAN and NAS and provides a framework for storage vendors to enable their unique capabilities and innovation. VVols will provide much more than VM-granular capabilities, they carry the potential to stop the fragmented data management we’ve adopted over the past 8 years and unify storage operations from application to infrastructure through backup and compliance.

 

Vendor specific capabilities are outside the scope of this post; however, we can discuss some capabilities that you should know when considering SAN or NAS with VVols.


5 Reasons why I believe you should consider SAN over NAS for VVols

  1. T10 UNMAP is an INCITS standard that will reduce storage requirements by enabling data that is deleted in a VM to be automatically deleted on the storage array. UNMAP is available today on a per VM basis with Hyper-V today and provides significant storage savings over the limited UNMAP capabilities in VMFS.
  2. T10 DIF is another INCITS standard and it will ensure end-to-end data integrity from application to array, reducing the requirement and system load in providing retroactive data validation in today’s storage arrays. DIF is designed to eliminate little known yet real-world issues like misdirected writes, writing incorrect data, over the wire corruption, etc.
  3. Greater support for applications. Some applications and application deployment scenarios either aren’t certified or simply cannot operate over NFS. I question some of the limitations, like the lack of NFS support with Microsoft Exchange Server, there are some limitations that appear will always exist with NFS. Microsoft Cluster Services (MCS) is one example where SCSI pass thru is required to deploy and SCSI-3 reservation support. While this capability is not in the current VVols beta, one should expect that VMware will look to provide this in a future release and in turn retire the need for RDMs.
  4. Enhanced storage bandwidth capabilities. This is an area where SAN has been and will continue to be more capable than NAS. The VVols beta currently does not include NFS v4.1 with pNFS, the latter is required for link aggregation. As such each VVol will be limited to a single link for IO with NFS and multi-links with SAN via VMware’s native or 3rd party multipathing software.
  5. Enhanced storage IO capabilities. Like the previous item, this is an area where SAN has been and will continue to be more capable than NAS. As the IO to an NFS VVol is limited to a single Ethernet link, any congestion cannot be addressed by VMware’s native or 3rd party multipathing software. Link congestion could manifest itself in a storage VMotion operation which will actual add load to the link, exacerbating the problem before it can shift IO access for the VM to another link.


In Closing…

 

Regardless of your preference for storage protocol with VMware, the SAN versus NAS debate has served all of us well. It provided customers with storage options that allowed them to advance their virtualization initiatives. NFS guided VMware, storage vendors and industry standards boards to develop new, optimized mechanisms better suited for virtual storage objects and paved the way for new storage vendors and their innovations to come to market.

 

I’ve long held fast to the notion that Ethernet provided the best solution when considering storage protocol with VMware. NFS provided simplicity with large shared datastores and iSCSI or FCoE enabled SCSI capabilities for applications requiring such connectivity.

 

As the IT industry has advanced so has my perspective. I rarely, if ever, speak to a customer struggling with the issues that led to the SAN versus NAS debate. Virtualization has matured into cloud computing, supporting business critical applications and large numbers of business process. Storage bottlenecks are still abundant but they are inherent in the workload cloud computing places disk based storage architectures and not the storage protocols. Flash addresses this issue.

 

As you look at VVols you should revisit the protocol your infrastructure runs on. Obviously if you’re on Fibre Channel, you’ll remain on Fibre Channel but if you’re a NFS customer on Ethernet you need to investigate what’s possible with iSCSI or FCoE and VVols.

 

There’s much more to discuss around VVols besides protocols, so stay tuned I’ve got more to share.

 

(this post originally appeared at The Virtual Storage Guy)


vSphere BDE Serengeti CLI で Hadoop クラスタ構築。(デフォルト編)

$
0
0

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 クラスタを作成してみる話でした。

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

$
0
0

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)

 

VMware Newsletter 6.37

$
0
0

From the editors virtual desk

Hi everyone, well I have had a really fantastic first week in San Francisco. I am feeling very productive already although I am still lacking some of my required technology updates which I hope will arrive soon.


Of course it was a busy tech week for many standing in line waiting for their new device. If you were waiting in line I hope that you managed to get the device you wanted. As for me as a new recruit to the USA I only just got my mobile phone plan so pre-ordered mine and managed to pick it up on launch day with very little hassle at all in downtown San Francisco.


I hope you enjoy the newsletter, I have been spending a bit of time refining the sections to make it even more readable.


Have a fantastic week everyone, drop me an email and say hi anytime.


Virtually Yours

Neil Isserow

Staff Technical Account Manager

VMware Inc - San Francisco, CA

nisserow @ vmware . com

 

LOCAL TRAINING CLASSES

http://tinyurl.com/m4wmen5 for full list

VMWARE BLOGGERS

VMware Newsletter 6.38

$
0
0

From the editors virtual desk

Hi everyone and greetings once again from San Francisco. Well it has been a very busy week. Of course the talk of the week is all about the latest vulnerability that has just been discovered that could affect all of us. This is the Bash Shell vulnerability. VMware, like many other vendors ships products that may be affected by this and as a result are providing guidance which I urge you to take note of and ensure that if they are relevant to your environment that you take the necessary precautions and discuss this further with your TAM.

Here is a link to the KB article which is being updated regularly: http://kb.vmware.com/kb/2090740

I have also written 2 blog posts this week on LinkedIn.

The first is Automating the Software Defined Data Center and can be found here: http://tinyurl.com/kmuoo2w

The next one is related to the Bas vulnerability and is a bit tongue in cheek but I think you will find it a bit of fun to read: http://tinyurl.com/l93r9vm

I hope you have a fantastic and productive week. Please feel free to get in touch anytime.

Virtually Yours
Neil Isserow

Staff Technical Account Manager
VMware Inc - San Francisco, CA
nisserow @ vmware . com

LOCAL TRAINING CLASSES

http://tinyurl.com/m4wmen5 for full list

VMWARE BLOGGERS

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

$
0
0

今回は、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 のクラスタを作成してみる話でした。

まだつづく・・・

Hands-On Labs and CloudCred - 2014 EMEA VMworld Labs Contest and Giveaways

$
0
0

Hands-On Labs and CloudCred - 2014 EMEA VMworld Labs Contest and Giveaways

WHAT: Hands-on Labs and CloudCred are teaming up at VMworld to reward you for doing something you already love doing, taking Labs!  By signing up for CloudCred and completing Labs, you will have the opportunity to win tons of exciting prizes.

HOW: First, make sure you are a CloudCred player! If you aren't yet, simply access the site and follow the simple instructions to sign up: CloudCredibility.com.  Then, once you are at VMworld and have completed a lab, a new screen will pop up asking you to take a survey, but you will also see a QR and verification code to signify that you have completed the task.  All you need to do is scan the QR code and it will take you directly to the CloudCred task for the lab where you can then enter the verification code to complete the task & receive points.  The verification code is unique to you and the lab you have completed.  In order for the lab to count, you will need to spend a minimum of 20 minutes in it.  If you don’t have a smartphone with you, just write down the code and enter it in when you have access to a computer.

WHAT CAN I WIN?

PRIZES:

Blog GoPro.jpg

 

 

 

Daily Leaders, T-Th: GoPro Hero 3 Camera

 

 

 

 

 

 

Blog Frogz.jpg




Final Leaders, Th, 5th-10th: iFrogz GoLite USB battery pack

 

 

 

 

 

 

 

 

Blog MyPassport.jpg

 

 

 

Final Leader, Th, 4th:MyPassport 1TB Hard Drive

 

 

 

 

 

 

 

Blog Jambox mini.png

 

 

 

 

Final Leader, Th, 3rd: Jambox Mini by Jawbone

 

 

 

 

 

 

 

Blog Beats headphones.jpg

 

 

 

Final Leader, Th, 2nd: Beats Solo HD Headphones

 

 

 

 

 

 

 

 

Blog Dell.jpg

 

 

Overall Grand Prize Winner!

Final Leader, Th, 1st: Dell Inspiron 15, 8gb i5 CPU

 

 

 

 

 

 

Other additional, cool prizes: 1st 4 to find a Hidden QRL Code win either a 3KmAmp USB Battery Pack or a 1 TB USB drive

So get ready to play and win with CloudCred & Hands-On Labs at 2014 EMEA VMworld! See you there!

*Maximum of one prize valued over $50 per player, includes daily leaders

vSphere BDE で Elastic Scaling してみる。第3回(Elasticity Mode:Auto)

$
0
0

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 についてでした。


VMware Newsletter 6.39

$
0
0

Email not displaying correctly? View it in your browser: http://us2.campaign-archive1.com/?u=84638d120599c4461b514e1a0&id=9bbde84b4a&e=[UNIQID]

From the editors virtual desk

Hi everyone, I hope you have had a productive week as I have. No new LinkedIn blogs however as I have been very busy working on a number of other initiatives for my customers. San Francisco has been awesome, it is so amazing to walk around and meet people who like me are so interested in the tech industry.

This week I attended the San Francisco VMUG (http://tinyurl.com/sfvmug).http://tinyurl.com/sfvmug).

This was my first VMUG outside of Australia and I must say it was awesome. The event was so well organised, from registration, to the venue, food and presentation. The session was on EVO:RAIL, something that I have been very interested to find out more about as my customers start to investigate these sorts of options for their own use cases. The access to partner and VMware experts was for everyone there I am sure a very rewarding experience as I think at least 50% of the session was Q&A style with very interesting and informative answers from the panel. If you are in the San Francisco or the Bay Area I suggest you check out the VMUG and attend the next session in your area as they do hold them in a number of locations.

I wish you a fantastic week, thank you for reading and supporting the newsletter.

Virtually Yours
Neil Isserow
Staff Technical Account Manager
VMware Inc - San Francisco, CA
nisserow @ vmware . com

LOCAL TRAINING CLASSES

http://tinyurl.com/m4wmen5 for full list

VMWARE BLOGGERS

VMware NSX for vSphere 6.1 Step-By-Step Installation

$
0
0

I know your excited to get right down to the meat of the installtion, but there is some housekeeping that we need to get out of the way first.  There are a number of pre-requisites that we need to ensure exist in the environment first.

 

Pre-requisites

  1. A properly configured vCenter Server with at least one cluster. (Ideally (2) clusters – (1) Management Cluster & 1(1) Cluster for everything else.)
  2. Cluster should have at least (2) hosts. (More would be better.  Memory will be important)
  3. You will need to be using Distributed Virtual Switches (DvSwitch) NOT Standard vSwitches.
  4. If you are NOT running vSphere 5.5 you will need to have your physical switches configured for Multicast. (Unicast requires vSphere 5.5)
  5. You will need a vLAN on your physical network that you can utilize for VXLAN.

To give you an idea below is the configuration for the “MoaC” lab that I will be working in.

MoaC Configuration

  • vCenter 5.5 U2b
  • (3) Clusters
    • Management Cluster with (2) vSphere  ESXi 5.5 U2 Hosts
      • 32GB Memory
      • Cluster only DvSwitch using NIC Teaming
    • Services Cluster with (4) vSphere ESXi 5.5 U2 Hosts
      • 196GB Memory
      • Cluster only DvSwitch using LAG.
    • Desktop Cluster with (2) vSphere ESXi 5.5 U2 Hosts
      • 112GB Memory
      • Cluster only DvSwitch using LAG.
  • Physical vLAN trunked to all vSphere hosts in all clusters.


[Ream More]

VMware NSX for vSphere 6.1 – Transport Zones

$
0
0

If you are familiar with “Network Scopes” from vCNS then “Transport Zones” should be familiar to you.  If not here is some useful information to know regarding these Zones.

Transport Zones dictate which clusters can participate in the use of a particular network.  Prior to creating your transport zones some thought should go into your network layout and what you want to be available to each cluster.  Below are some different scenarios for transport zones.

 

In the “MoaC” environment I have three clusters.  There is a Management Cluster in which all management servers are hosted included all components of NSX which will include all Logical and Edge routers that we have not yet configured, but this concept is important to know.  I will not be placing any routers in any other cluster than my management cluster.  I then have a Services cluster which will be hosting all of my provisioned machines that are not part of the core infrastructure, and finally I have a desktop cluster in which I will be hosting VDI desktop instances.

 

[Read More]

VMware NSX for vSphere 6.1 Step-By-Step Installation

$
0
0

I know your excited to get right down to the meat of the installtion, but there is some housekeeping that we need to get out of the way first.  There are a number of pre-requisites that we need to ensure exist in the environment first.

 

Pre-requisites

  1. A properly configured vCenter Server with at least one cluster. (Ideally (2) clusters – (1) Management Cluster & 1(1) Cluster for everything else.)
  2. Cluster should have at least (2) hosts. (More would be better.  Memory will be important)
  3. You will need to be using Distributed Virtual Switches (DvSwitch) NOT Standard vSwitches.
  4. If you are NOT running vSphere 5.5 you will need to have your physical switches configured for Multicast. (Unicast requires vSphere 5.5)
  5. You will need a vLAN on your physical network that you can utilize for VXLAN.

To give you an idea below is the configuration for the “MoaC” lab that I will be working in.

MoaC Configuration

  • vCenter 5.5 U2b
  • (3) Clusters
    • Management Cluster with (2) vSphere  ESXi 5.5 U2 Hosts
      • 32GB Memory
      • Cluster only DvSwitch using NIC Teaming
    • Services Cluster with (4) vSphere ESXi 5.5 U2 Hosts
      • 196GB Memory
      • Cluster only DvSwitch using LAG.
    • Desktop Cluster with (2) vSphere ESXi 5.5 U2 Hosts
      • 112GB Memory
      • Cluster only DvSwitch using LAG.
  • Physical vLAN trunked to all vSphere hosts in all clusters.

 

[Read More]

VMware NSX for vSphere 6.1 – Transport Zones

$
0
0

If you are familiar with “Network Scopes” from vCNS then “Transport Zones” should be familiar to you.  If not here is some useful information to know regarding these Zones.

Transport Zones dictate which clusters can participate in the use of a particular network.  Prior to creating your transport zones some thought should go into your network layout and what you want to be available to each cluster.  Below are some different scenarios for transport zones.

In the “MoaC” environment I have three clusters.  There is a Management Cluster in which all management servers are hosted included all components of NSX which will include all Logical and Edge routers that we have not yet configured, but this concept is important to know.  I will not be placing any routers in any other cluster than my management cluster.  I then have a Services cluster which will be hosting all of my provisioned machines that are not part of the core infrastructure, and finally I have a desktop cluster in which I will be hosting VDI desktop instances.

 

[Read More]

Viewing all 3135 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>