Skip navigation

ひきつづき、VMware NSX for vSphere の HoL シナリオを PowerNSX で進めてみます。

 

前回までの投稿はこちら。

NSX の HoL シナリオを PowerNSX でためす。Part.1(論理スイッチ 作成 / ESG 接続)

NSX の HoL シナリオを PowerNSX でためす。Part.2(DLR 接続 / OSPF 設定)

 

今回も、下記のラボを利用します。

HOL-1803-01-NET - VMware NSX - Getting Started

http://labs.hol.vmware.com/HOL/catalogs/lab/3661

 

今回は、モジュール3 の続きです。

ここでは、この先に ECMP ルーティングの構成する準備として、

ラボに 2台目の NSX Edge Service Gateway(ESG)をデプロイします。

 

New-NsxEdge の都合上、クラスタでは DRS を有効にしてしまいます。

管理クラスタには NSX Controller も配置されているので、アンチアフィニティ ルールの都合上

可能なら DRS は有効にしておいた方がよい気がします。

ただし、ESG は基本的に常にトラフィックが発生するので

DRS を有効にしても、DRS のポリシーは必ずしも完全自動にはしなくてもよいかなと考えられます。

Get-Cluster RegionA01-MGMT01 | Set-Cluster -DrsEnabled:$true -Confirm:$false

hol1803-powernsx-03-00.png

 

ESG をデプロイする前に、New-NsxEdgeInterfaceSpec で

ESG のインターフェース設定を用意しておきます。

 

アップリンク側です。vNIC は vDS の分散ポートグループに接続します。

$vnic0 = New-NsxEdgeInterfaceSpec -Index 0 -Name Uplink -Type uplink -ConnectedTo (Get-VDPortgroup Uplink-RegionA01-vDS-MGMT) -PrimaryAddress 192.168.100.4 -SubnetPrefixLength 24

hol1803-powernsx-03-01.png

 

インターナル側です。vNIC は NSX の論理スイッチに接続します。

$vnic1 = New-NsxEdgeInterfaceSpec -Index 1 -Name Transit_Network_01 -Type internal -ConnectedTo (Get-NsxLogicalSwitch -Name Transit_Network_01) -PrimaryAddress 192.168.5.4 -SubnetPrefixLength 29

hol1803-powernsx-03-02.png

 

そして、NSX Edge をデプロイします。

New-NsxEdge -Name Perimeter-Gateway-02 -Username admin -Password "VMware1!VMware1!" -EnableSSH -Cluster (Get-Cluster RegionA01-MGMT01) -Datastore (Get-Datastore RegionA01-ISCSI01-COMP01) -FormFactor compact -Interface $vnic0,$vnic1 -FwEnabled -FwDefaultPolicyAllow

hol1803-powernsx-03-03.png

 

NSX Edge のデプロイは NSX のコンポーネントの中でも入力項目が多く失敗した時の悲しみが大きいので、

コマンドラインを用意しておくことで、成功率を上げたり、リトライしやすくすると便利かなと思います。

 

また経験上、Nsx Edge のデプロイが成功しない場合はまず下記のあたりを確認するとよさそうです。

  • デプロイ先のクラスタで DRS が有効になっているか。
  • インターフェースに指定した IP アドレスが正しいか。(ネットワーク アドレス的にも)
  • New-NsxEdgeInterfaceSpec や New-NsxEdge で指定しているオブジェクトが本当に存在しているか。
  • 指定したオブジェクトの名前が重複していないか。(同一 Edge での New-NsxEdgeInterfaceSpec の Name も)

 

まだまだ続く。

NSX の HoL シナリオを PowerNSX でためす。Part.4(ECMP 設定)

VMware NSX for vSphere の HoL シナリオを PowerNSX で進めてみます。

 

前回の投稿はこちら。

NSX の HoL シナリオを PowerNSX でためす。Part.1(論理スイッチ 作成 / ESG 接続)

 

今回も、下記のラボを利用します。

HOL-1803-01-NET - VMware NSX - Getting Started

http://labs.hol.vmware.com/HOL/catalogs/lab/3661

 

今回は、モジュール3 の分散論理ルーティングを実施します。

このシナリオでは、Edge Service Gateway(ESG)でのルーティングを

分散論理ルータ(DLR)によるルーティングに変更して、

さらに ESG / DLR で OSPF によるダイナミック ルーティングを有効化します。

 

ESG から DLR へのインターフェース付け替え。

 

まず PowerShell を起動して、NSX Manager と vCenter に接続しておきます。

Connect-NsxServer -vCenterServer vcsa-01a.corp.local -Username administrator@corp.local -Password VMware1!

 

このラボのサンプル Web ページ「Customer DB App」は、

はじめは NSX Edge Service Gateway(ESG)でルーティングをしています。

まず、ESG のインターフェースの構成を確認しておきます。

Get-NsxEdge -Name Perimeter-Gateway-01 | Get-NsxEdgeInterface | select index,name,type,isConnected,portgroupName | ft -AutoSize

hol1803-powernsx-02-01.png

 

構成変更のため、ESG からインターフェース App_Tier と DB_Tier を削除します。

vnic3、vnic4 がクリアされます。

Get-NsxEdge -Name Perimeter-Gateway-01 | Get-NsxEdgeInterface -Name  App_Tier | Clear-NsxEdgeInterface -Confirm:$false

Get-NsxEdge -Name Perimeter-Gateway-01 | Get-NsxEdgeInterface -Name  DB_Tier | Clear-NsxEdgeInterface -Confirm:$false

hol1803-powernsx-02-02.png

 

新たにネットワークを接続する、DLR のインターフェース構成を確認しておきます。

Get-NsxLogicalRouter -Name Distributed-Router-01 | Get-NsxLogicalRouterInterface | %{$ip = $_.addressGroups.addressGroup; $_ | select Index,type,name,connectedToName,{$ip.primaryAddress},{$ip.subnetPrefixLength}} | ft -AutoSize

hol1803-powernsx-02-03.png

 

論理スイッチを接続します。

$ls = Get-NsxLogicalSwitch -Name App_Tier_Logical_Switch

Get-NsxLogicalRouter -Name Distributed-Router-01 | New-NsxLogicalRouterInterface -Name App_Tier -Type internal -ConnectedTo $ls -PrimaryAddress 172.16.20.1 -SubnetPrefixLength 24

 

接続する論理スイッチは、下記のように指定することもできます。

Get-NsxLogicalRouter -Name Distributed-Router-01 | New-NsxLogicalRouterInterface -Name DB_Tier -Type internal -ConnectedTo (Get-NsxLogicalSwitch -Name DB_Tier_Logical_Switch) -PrimaryAddress 172.16.30.1 -SubnetPrefixLength 24

hol1803-powernsx-02-05.png

 

DLR に、論理スイッチに接続したインターフェース App_Tier、DB_Tier が作成されました。

hol1803-powernsx-02-06.png

 

DLR で OSPF を有効化する。

DLR は、OSPF がまだ無効な状態です。

Get-NsxLogicalRouter -Name Distributed-Router-01 | Get-NsxLogicalRouterRouting | Get-NsxLogicalRouterOspf

hol1803-powernsx-02-07.png

 

DLR で OSPF を有効化します。

Get-NsxLogicalRouter -Name Distributed-Router-01 | Get-NsxLogicalRouterRouting | Set-NsxLogicalRouterRouting -EnableOspf -EnableOspfRouteRedistribution -RouterId 192.168.5.2 -ProtocolAddress 192.168.5.3 -ForwardingAddress 192.168.5.2 -Confirm:$false

hol1803-powernsx-02-08.png

 

OSPF Area を作成します。

Get-NsxLogicalRouter -Name Distributed-Router-01 | Get-NsxLogicalRouterRouting | New-NsxLogicalRouterOspfArea -AreaId 10 -Confirm:$false

hol1803-powernsx-02-09.png

 

DLR のアップリンク インターフェースに OSPF Area を追加します。

$if = Get-NsxLogicalRouter -Name Distributed-Router-01 | Get-NsxLogicalRouterInterface -Name Transit_Network_01

Get-NsxLogicalRouter -Name Distributed-Router-01 | Get-NsxLogicalRouterRouting | New-NsxLogicalRouterOspfInterface -Vnic $if.index -AreaId 10 -Confirm:$false

hol1803-powernsx-02-10.png

 

分散ルータで OSPF が有効になりました。

hol1803-powernsx-02-11.png

 

OSPF のルート再配布テーブルに BGP の許可ルールを追加しておきます。

(本来ならルール編集がいいとは思いますが・・・)

Get-NsxLogicalRouter -Name Distributed-Router-01 | Get-NsxLogicalRouterRouting | New-NsxLogicalRouterRedistributionRule -Learner ospf -FromBGP -Action permit -Confirm:$false

 

 

NSX ESG に OSPF ルーティングを追加する。

NSX ESG も、まだ OSPF が無効です。

Get-NsxEdge -Name Perimeter-Gateway-01 | Get-NsxEdgeRouting | Get-NsxEdgeOspf

hol1803-powernsx-02-12.png

 

ESG で OSPF を有効化します。

Get-NsxEdge -Name Perimeter-Gateway-01 | Get-NsxEdgeRouting | Set-NsxEdgeRouting -EnableOspf -EnableOspfRouteRedistribution -Confirm:$false

hol1803-powernsx-02-13.png

 

OSPF Area を作成します。

Get-NsxEdge -Name Perimeter-Gateway-01 | Get-NsxEdgeRouting | New-NsxEdgeOspfArea -AreaId 10 -Confirm:$false

hol1803-powernsx-02-14.png

 

ESG のインターフェースに OSPF Area を追加します。

$if = Get-NsxEdge -Name Perimeter-Gateway-01 | Get-NsxEdgeInterface -Name Transit_Network_01

Get-NsxEdge -Name Perimeter-Gateway-01 | Get-NsxEdgeRouting | New-NsxEdgeOspfInterface -Vnic $if.index -AreaId 10 -Confirm:$false

hol1803-powernsx-02-15.png

 

今回はルート再配布テーブルに許可ルールを追加してしまいます。

(こちらも本来はルール編集がいいとは思いますが・・・)

Get-NsxEdge -Name Perimeter-Gateway-01 | Get-NsxEdgeRouting | New-NsxEdgeRedistributionRule -Learner bgp -FromOspf -Action permit -Confirm:$false

Get-NsxEdge -Name Perimeter-Gateway-01 | Get-NsxEdgeRouting | New-NsxEdgeRedistributionRule -Learner ospf -FromBGP -FromConnected -Action permit -Confirm:$false

 

これで、ネットワーク構成を変更したあとも

HoL のサンプル Web ページ「Customer DB App」が表示できるようになるはずです。

 

つづく。

NSX の HoL シナリオを PowerNSX でためす。Part.3(NSX Edge デプロイ)

VMware NSX for vSphere は REST API で操作することができます。

しかし運用手順の自動化をするときには、API を直接利用するよりも、

PowerShell などを介して利用する方が便利なことがあります。

そこで、PowerShell ベースのツールである PowerNSX で HoL のシナリオを進めてみます。

 

今回は、下記のラボを利用します。

 

HOL-1803-01-NET - VMware NSX - Getting Started

http://labs.hol.vmware.com/HOL/catalogs/lab/3661

 

PowerNSX での NSX Manager / vCenter への接続。

このラボには PowerNSX の PowerShell モジュールがインストールされています。

そのため PowerShell を起動すれば、そのまま PowerNSX が利用可能です。

hol1803-powernsx-01-01.png

 

PowerShell を起動して NSX Manager / vCenter へ接続し、NSX のバージョンを確認しておきます。

※コマンドラインは「テキストの送信」でコピー&ペーストできます。

Connect-NsxServer -vCenterServer vcsa-01a.corp.local -Username administrator@corp.local -Password VMware1!

 

NSX 6.3.1 であることがわかります。

hol1803-powernsx-01-02.png

 

論理スイッチを作成する。

それでは、ラボのモジュール 2 のシナリオに沿って論理スイッチを作成します。

 

PowerNSX でのオブジェクト作成ではトランスポート ゾーンを指定することが多いので

あらかじめ Get-NsxTransportZone で取得しておきます。

$tz = Get-NsxTransportZone

$tz

hol1803-powernsx-01-03.png

 

論理スイッチを作成します。

New-NsxLogicalSwitch -TransportZone $tz -Name Prod_Logical_Switch

 

論理スイッチが作成されました。

hol1803-powernsx-01-03a.png

 

vSphere Web Client でも、論理スイッチが作成されたことが確認できます。

hol1803-powernsx-01-04.png

 

ラボマニュアルでの指定どおりの設定になっています。

hol1803-powernsx-01-05.png

 

ESG に論理スイッチを接続する。

作成した論理スイッチを、NSX Edge Service Gateway(ESG)のインターフェースに接続します。

対象の ESG は下記です。

Get-NsxEdge -Name Perimeter-Gateway-01

hol1803-powernsx-01-06.png

 

ESG のインターフェースの構成は、下記のように確認できます。

Get-NsxEdge -Name Perimeter-Gateway-01 | Get-NsxEdgeInterface | select index,name,isConnected,portgroupName

hol1803-powernsx-01-07.png

 

VM を接続する論理スイッチ(先ほど作成したもの)を取得します。

$ls = Get-NsxLogicalSwitch -TransportZone $tz -Name Prod_Logical_Switch

$ls

hol1803-powernsx-01-08.png

 

ESG に論理スイッチを接続します。

Get-NsxEdge -Name Perimeter-Gateway-01 | Get-NsxEdgeInterface -Index 7 | Set-NsxEdgeInterface -Name Prod_Interface -type internal -Connected:$true -PrimaryAddress 172.16.40.1 -SubnetPrefixLength 24 -ConnectedTo $ls

hol1803-powernsx-01-09.png

 

vSphere Web Client でもインターフェースの設定変更が確認できます。

hol1803-powernsx-01-10.png

 

論理スイッチへの VM の接続。

作成した論理スイッチに、VM を接続します。

本来であれば、論理スイッチには vNIC を指定して接続しますが、

今回の VM は、それぞれ vNIC を 1つだけもっているので VM を指定して接続します。

 

今回の対象 VM は下記(web-03a、web-04a)です。各 VM の vNIC は1つだけです。

Get-VM web-0[34]a.corp.local

Get-VM web-0[34]a.corp.local | Get-NetworkAdapter | ft -AutoSize

hol1803-powernsx-01-11.png

 

vNIC が1つだけなので、VM を指定して接続します。

$vms = Get-VM web-0[34]a.corp.local

Connect-NsxLogicalSwitch -VirtualMachine $vms -LogicalSwitch $ls

 

接続されました。論理スイッチのバッキング ポートグループが接続されています。

hol1803-powernsx-01-12.png

 

vSphere Web Client でも、論理スイッチに VM が接続されたことが確認できます。

hol1803-powernsx-01-13.png

 

そして HoL のシナリオにあるように、web-03a と web-04a とで ping による疎通確認ができるはずです。

 

つづく・・・

NSX の HoL シナリオを PowerNSX でためす。Part.2(DLR 接続 / OSPF 設定)

vSAN データストアには、osfs-mkdir コマンドでディレクトリ(namespace オブジェクト)を作成すると

一般的なファイル(ISO イメージなど)を配置できるようになります。

 

Unable to upload, copy or create files in a VMware vSAN-backed datastore (2119776)

https://kb.vmware.com/s/article/2119776

 

ふと、ISO のような一般的なファイルを配置した場合に

仮想マシン ストレージ ポリシー がどう適用されるのか気になったので確認してみました。

 

今回の環境は、vCenter 6.5 U1 です。

vSAN データストアには、下記のように

デフォルトのストレージポリシーとして「vsan-policy-raid5」を設定しています。

vsan-file-policy-01.png

 

このとき、とくに仮想マシン ストレージ ポリシーを指定せずに

VM を作成すると、データストアのデフォルトの仮想マシン ストレージ ポリシーが設定されます。

 

VM 作成時の 仮想マシン ストレージ ポリシーの様子。

 

まず、VM を作成した場合のポリシーの様子です。

たとえば PowerCLI で下記のように VM を作成すると・・・

PowerCLI> New-VM -Name vsan-test-vm -Datastore vsanDatastore-01 -ResourcePool vsan-cluster-01

 

 

Name                 PowerState Num CPUs MemoryGB

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

vsan-test-vm         PoweredOff 1        0.250

 

 

vsanDatastore-01 のデフォルトの仮想マシン ストレージ ポリシーが設定されます。

PowerCLI> Get-VM vsan-test-vm | Get-SpbmEntityConfiguration | Format-List Entity,StoragePolicy,ComplianceStatus

 

 

Entity           : vsan-test-vm

StoragePolicy    : vsan-policy-raid5

ComplianceStatus : compliant

 

 

PowerCLI> Get-VM vsan-test-vm | Get-HardDisk | Get-SpbmEntityConfiguration | Format-List Entity,StoragePolicy,ComplianceStatus

 

 

Entity           : Hard disk 1

StoragePolicy    : vsan-policy-raid5

ComplianceStatus : compliant

 

 

vSphere Web Client から見ても、ポリシーが設定されています。

 

仮想ディスクと・・・

vsan-file-policy-02.png

 

仮想マシン ホームのオブジェクトには、どちらもデフォルトのポリシーが設定されました。

vsan-file-policy-03.png

 

vSAN データストアにファイル配置した時のポリシー。

 

ESXi に SSH でログインして、ディレクトリ(namespace object)を作成します。

 

ESXi 6.5 U1 です。

[root@hv-i21:~] vmware -vl

VMware ESXi 6.5.0 build-7388607

VMware ESXi 6.5.0 Update 1

 

osfs-mkdir でディレクトリを作成します。

[root@hv-i21:~] /usr/lib/vmware/osfs/bin/osfs-mkdir /vmfs/volumes/vsanDatastore-01/work

7259115b-7e8f-8fb0-8e97-b8aeedea7a23

 

今回は、cp コマンドで、ISO イメージ ファイル(photon-2.0-304b817.iso)を配置します。

ISO イメージ ファイルは、あらかじめ NFS データストアを用意して、そこに配置してあります。

[root@hv-i21:~] cp /vmfs/volumes/ds-nfs-work-01/iso/VMware/photon-2.0-304b817.iso /vmfs/volumes/vsanDatastore-01/work/

 

ファイルが配置されました。

[root@hv-i21:~] ls -l /vmfs/volumes/vsanDatastore-01/work

lrwxr-xr-x    1 root     root            36 Jun  1 14:43 /vmfs/volumes/vsanDatastore-01/work -> 7259115b-7e8f-8fb0-8e97-b8aeedea7a23

[root@hv-i21:~] ls -l /vmfs/volumes/vsanDatastore-01/work/

total 2317312

-rw-r--r--    1 root     root     2372728832 Jun  1 14:41 photon-2.0-304b817.iso

 

UUID をもとに Other の vSAN オブジェクトを確認すると、

ポリシー設定されていない状態に見えます。

vsan-file-policy-04.png

 

ちなみに、esxcli では下記のように見えます。

Type は、namespace になっています。そして vSphere Web Client でみたとおり、

vSAN オブジェクトのコンポーネントは RAID5 にならず 1つだけです。

 

実行したコマンド:

esxcli vsan debug object list -u <UUID。今回は namespace オブジェクトの UUID>

 

vsan-file-policy-05.png

 

vSAN データストアには、できるだけ VM / VMDK にかかわるファイルだけ配置して、

ISO イメージのようなものは NFS データストアなどを用意して配置する方が

よいかもしれません。

 

以上、vSAN データストアにファイルを配置してみる話でした。

PowerCLI では、VMware Tools のインストールされているゲスト OS の

ファイルシステムの使用状況が確認できます。

 

ためしに vCenter PSC の仮想マシン(vc-psc01)で、ゲスト OS のファイルシステム使用状況を取得してみます。

今回は、PowerCLI 10.1 で vCenter 6.5 U1 に接続しています。

 

ゲスト OS に、VMware Tools 10.1.5 がインストールされていることがわかります。

PowerCLI> Get-VM vc-psc01 | Get-VMGuest | select VM,ToolsVersion | fl

 

VM           : vc-psc01

ToolsVersion : 10.1.5

 

 

vCenter Server Appliance 6.5 なので、ゲスト OS の種類は Linux(VMware Photon OS) です。

ファイルシステムのマウントされている Path ごとに、全体の容量と空き容量がわかります。

PowerCLI> $guest = Get-VM vc-psc01 | Get-VMGuest

PowerCLI> $guest.Disks | ft -AutoSize

 

CapacityGB FreeSpaceGB Path

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

10.575     7.271       /

0.117      0.091       /boot

0.007      0.007       /storage/imagebuilder

0.007      0.007       /storage/autodeploy

0.007      0.007       /storage/updatemgr

0.007      0.007       /storage/dblog

0.007      0.007       /storage/seat

0.007      0.007       /storage/netdump

9.710      9.688       /storage/core

9.710      9.647       /storage/db

9.710      8.103       /storage/log

 

 

たとえば下記のようなスクリプトで、仮想マシンごとのファイルシステム使用率を取得したりできます。

get_guest_fs_usage.ps1 · GitHub

$vm_names = $args[0]

$vms = Get-VM $vm_names

 

$vms | % {

    $vm = $_

    $guest = $vm.Guest

    $guest.Disks | select `

        @{N="VM";E={$vm.Name}},

        Path,

        @{N="CapacityGB";E={"{0:0.0}" -f $_.CapacityGB}},

        @{N="FreeSpaceGB";E={"{0:0.0}" -f $_.FreeSpaceGB}},

        @{N="UsagePCT";E={

            $usage_pct = 100 - ($_.FreeSpaceGB / $_.CapacityGB * 100)

            "{0:0.0}" -f $usage_pct}}

}

 

仮想マシン名を指定して実行すると、下記のようになります。

今回は、vc-sv01 と vc-psc01 という仮想マシンの情報を取得しています。

PowerCLI> .\get_guest_fs_usage.ps1 vc-sv01,vc-psc01 | ft -AutoSize

 

VM       Path                  CapacityGB FreeSpaceGB UsagePCT

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

vc-psc01 /                     10.6       7.3         31.2

vc-psc01 /boot                 0.1        0.1         22.5

vc-psc01 /storage/imagebuilder 0.0        0.0         0.7

vc-psc01 /storage/autodeploy   0.0        0.0         0.7

vc-psc01 /storage/updatemgr    0.0        0.0         0.7

vc-psc01 /storage/dblog        0.0        0.0         0.7

vc-psc01 /storage/seat         0.0        0.0         0.7

vc-psc01 /storage/netdump      0.0        0.0         0.7

vc-psc01 /storage/core         9.7        9.7         0.2

vc-psc01 /storage/db           9.7        9.6         0.7

vc-psc01 /storage/log          9.7        8.1         16.5

vc-sv01  /                     10.6       4.9         53.3

vc-sv01  /boot                 0.1        0.1         22.5

vc-sv01  /storage/autodeploy   9.7        9.7         0.2

vc-sv01  /storage/netdump      1.0        1.0         0.1

vc-sv01  /storage/seat         9.7        9.2         4.9

vc-sv01  /storage/core         24.5       24.4        0.2

vc-sv01  /storage/imagebuilder 9.7        9.7         0.2

vc-sv01  /storage/updatemgr    98.3       97.5        0.9

vc-sv01  /storage/db           9.7        9.5         2.6

vc-sv01  /storage/log          9.7        7.9         18.6

vc-sv01  /storage/dblog        14.6       14.5        0.9

 

 

ゲスト OS が Windows の場合は、Path にはドライブ レター(C: など)が表示されます。

PowerCLI> .\get_guest_fs_usage.ps1 *win* | ft -AutoSize

 

VM        Path CapacityGB FreeSpaceGB UsagePCT

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

lab-win01 C:\  39.7       27.0        32.0

lab-win02 C:\  39.7       27.7        30.2

 

 

ちなみに、VMware Tools から情報取得できるので、

vCenter や vRealize Operations Manager でも、ゲスト OS のファイルシステム使用状況はわかります。

vrops-guest-fs-usage.png

 

PowerCLI でのゲスト OS の情報確認については下記もどうぞ。

PowerCLI で ゲスト OS の vNIC と IP アドレスの対応を確認してみる。

 

以上、PowerCLI でのゲスト OS 情報取得についてでした。

PowerCLI を利用して、vSAN 6.7 の Witness Appliance をデプロイしてみます。

 

今回の環境。

vSAN Witness Appliance をデプロイする vCenter と、

登録する(vSAN クラスタを構成する)vCenter は別にしています。

 

vSAN Witness Appliance のデプロイ。

まず vCenter に接続します。

PowerCLI> Connect-VIServer vc-sv01.go-lab.jp

 

今回は、vSAN 6.7 の Witness Appliance の ova ファイル

(VMware-VirtualSAN-Witness-6.7.0-8169922.ova)をデプロイします。

PowerCLI> $ovf_config = Get-OvfConfiguration -Ovf E:\VMware\VMware-VirtualSAN-Witness-6.7.0-8169922.ova

 

入力するパラメータは、下記のような感じです。

PowerCLI> $ovf_config

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

OvfConfiguration: VMware-VirtualSAN-Witness-6.7.0-8169922.ova

 

   Properties:

   -----------

   DeploymentOption

   NetworkMapping

   vsan

 

 

PowerCLI> $ovf_config.DeploymentOption

 

 

Key                : DeploymentOption

Value              :

DefaultValue       : normal

OvfTypeDescription : string["tiny", "normal", "large"]

Description        : Tiny (10 VMs or fewer)

                     Configuration for Tiny vSAN Deployments with 10 VMs or fewer

 

                     * 2 vCPUs

                     * 8GB vRAM

                     * 1x 12GB ESXi Boot Disk

                     * 1x 15GB Magnetic Disk

                     * 1x 10GB Solid-State Disk

                     * Maximum of 750 Witness Components

 

                     Medium (up to 500 VMs)

                     Configuration for Medium vSAN Deployments of up to 500 VMs

 

                     * 2 vCPUs

                     * 16GB vRAM

                     * 1x 12GB ESXi Boot Disk

                     * 1x 350GB Magnetic Disk

                     * 1x 10GB Solid-State Disk

                     * Maximum of 22K Witness Components

 

                     Large (more than 500 VMs)

                     Configuration for Large vSAN Deployments of more than 500 VMs

 

                     * 2 vCPUs

                     * 32GB vRAM

                     * 1x 12GB ESXi Boot Disk

                     * 3x 350GB Magnetic Disks

                     * 1x 10GB Solid-State Disk

                     * Maximum of 45K Witness Components

 

 

PowerCLI> $ovf_config.NetworkMapping | fl

 

 

Management_Network :

Witness_Network    :

 

 

PowerCLI> $ovf_config.vsan.witness.root.passwd

 

 

Key                : vsan.witness.root.passwd

Value              :

DefaultValue       :

OvfTypeDescription : password(7..)

Description        : Set password for root account.

 

                        A valid password must be at least 7 characters long and must contain a mix

                        of upper and lower case letters, digits, and other characters.  You can use

                        a 7 character long password with characters from at least 3 of these 4

                        classes.  An upper case letter that begins the password and a digit that

                        ends it do not count towards the number of character classes used.

 

 

パラメータを設定します。デプロイします。

今回は、直接接続の 2 ノード vSAN にする想定として、

vSAN Witness Appliance の Management / vSAN トラフィックは vmk0 ポートを併用します。

ここでは Management_Network / Witness_Network 両方に同じポートグループを指定していますが、

vmk1 を接続する vNIC は、後で切断状態にしてしまいます。

PowerCLI> $ovf_config.vsan.witness.root.passwd.Value = "パスワード"

PowerCLI> $ovf_config.NetworkMapping.Management_Network.Value = "dvpg-vds01-vlan-0000"

PowerCLI> $ovf_config.NetworkMapping.Witness_Network.Value = "dvpg-vds01-vlan-0000"

PowerCLI> $ovf_config.DeploymentOption.Value = "tiny"

 

Import-VApp でデプロイします。オプションは下記のようにしています。

  • VM 名: hv-n23w ※Nested ESX の VM。
  • デプロイ先の ESXi: hv-i21.go-lab.jp
  • デプロイ先データストアも vSAN ※ただし今回の vSAN とは別。
  • デプロイ先のフォルダ: test

PowerCLI> Import-VApp -Name hv-n23w -OvfConfiguration $ovf_config -Source $ovf_config.Source -VMHost hv-i21.go-lab.jp -Datastore vsanDatastore-01 -StorageFormat Thin -InventoryLocation (Get-Folder -Type VM test)

 

今回は2つ目の vNIC を使用しないので、切断状態にしておきます。

PowerCLI> Get-VM hv-n23w | Get-NetworkAdapter -Name "Network adapter 2" | Set-NetworkAdapter -StartConnected:$false -Confirm:$false

 

VM を起動します。

PowerCLI> Get-VM hv-n23w | Start-VM

 

ゲスト OS の ESXi が起動するまで待ちます。

PowerCLI> Get-VM hv-n23w | Get-VMGuest | ft -AutoSize State,OSFullName,IPAddress

 

  State OSFullName      IPAddress

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

Running VMware ESXi 6.5 {192.168.1.42, fe80::250:56ff:fe8a:1896, 2400:4030:8c62:5400:250:56ff:fe8a:1896, fe80::250:5...

 

 

vSAN Witness Appliance のネットワーク設定。

vCenter に登録する準備として、ネットワーク設定をします。

通常は vSAN Witness Appliance の VM コンソールを開いて DCUI から設定しますが、

ここでは、前回の投稿でのスクリプトを利用して設定してみます。

PowerCLI から Nested ESXi の esxcli を実行してみる。(GuestProcessManager)

 

vCenter に接続していない場合は、あらかじめ接続した状態でスクリプトを実行します。

PowerCLI> Connect-VIServer vc-sv01.go-lab.jp -Force

PowerCLI> .\invoke_nested-esxcli.ps1 system hostname set --host hv-n23w --domain go-lab.jp -ESXiVM:hv-n23w -ESXiUser:root -ESXiPass:パスワード

PowerCLI> .\invoke_nested-esxcli.ps1 network ip interface ipv4 set --interface-name=vmk0 --type=static --ipv4=192.168.1.217 --netmask=255.255.255.0 --gateway=192.168.1.1 -ESXiVM:hv-n23w -ESXiUser:root -ESXiPass:パスワード

 

少し待つと、VMware Tools から取得した情報でも設定が反映されたことが分かります。

PowerCLI> Get-VM hv-n23w | Get-VMGuest | fl HostName,IPAddress

 

HostName  : hv-n23w.go-lab.jp

IPAddress : {192.168.1.217, fe80::250:56ff:fe8a:1896, 2400:4030:8c62:5400:250:56ff:fe8a:1896, 169.254.80.14...}

 

 

疎通確認をしておきます。

PowerCLI> Test-Connection -Quiet 192.168.1.217

True

PowerCLI> ping 192.168.1.217

 

192.168.1.217 に ping を送信しています 32 バイトのデータ:

192.168.1.217 からの応答: バイト数 =32 時間 <1ms TTL=64

192.168.1.217 からの応答: バイト数 =32 時間 <1ms TTL=64

192.168.1.217 からの応答: バイト数 =32 時間 <1ms TTL=64

192.168.1.217 からの応答: バイト数 =32 時間 <1ms TTL=64

 

192.168.1.217 の ping 統計:

    パケット数: 送信 = 4、受信 = 4、損失 = 0 (0% の損失)、

ラウンド トリップの概算時間 (ミリ秒):

    最小 = 0ms、最大 = 0ms、平均 = 0ms

PowerCLI>

 

いったん、PowerCLI をデプロイ先の vCenter から切断します。

PowerCLI> Disconnect-VIServer -Confirm:$false

 

vSAN Witness Appliance の vCenter 登録。

vSAN Witness Appliance を登録します。

 

vSAN クラスタをセットアップする予定の vCenter に接続します。

PowerCLI> Connect-VIServer vc-sv02.go-lab.jp -Force

 

vSAN Witness Appliance は、通常の ESXi と同様に vCenter に登録します。

vCenter インベントリのデータセンタ(dc02)は既に作成してあります。

ESXi の root ユーザ / デプロイ時に指定したパスワード でログインします。

PowerCLI> Get-Datacenter -Name dc02 | Add-VMHost -Name hv-n23w.go-lab.jp -Force

 

検証しやすいように、SSH を有効化 / サービス起動してしまいます。

PowerCLI> $hv = Get-VMHost hv-n23w.go-lab.jp

PowerCLI> $hv | Get-VMHostService | where {$_.key -eq "TSM-SSH"} | Set-VMHostService -Policy On -Confirm:$false

PowerCLI> $hv | Get-VMHostService | where {$_.key -eq "TSM-SSH"} | Start-VMHostService

 

DNS Server のアドレスを設定しておきます。

ここでは 192.168.1.254, 192.168.1.253 の 2台を参照するように設定しています。

PowerCLI> $hv | Get-VMHostNetwork | Set-VMHostNetwork -DnsAddress 192.168.1.254,192.168.1.253

 

vmk0 の vSAN タグを有効にしておきます。

PowerCLI> Get-VMHost hv-n23w.go-lab.jp | Get-VMHostNetworkAdapter -Name vmk0 | Set-VMHostNetworkAdapter -VsanTrafficEnabled:$true -Confirm:$false

 

vmk1 の IP アドレス、vSAN タグを無効化しておきます。

PowerCLI> Get-VMHost hv-n23w.go-lab.jp | Get-VMHostNetworkAdapter -Name vmk1 | Set-VMHostNetworkAdapter -IP 0.0.0.0 -SubnetMask 255.255.255.255 -VsanTrafficEnabled:$false -Confirm:$false

 

VMkernel ポートが設定変更されました。

PowerCLI> Get-VMHost hv-n23w.go-lab.jp | Get-VMHostNetworkAdapter -VMKernel | ft -AutoSize Name,PortGroupName,VsanTrafficEnabled,IP,SubnetMask

 

Name PortGroupName      VsanTrafficEnabled IP            SubnetMask

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

vmk0 Management Network               True 192.168.1.217 255.255.255.0

vmk1 witnessPg                       False

 

 

このあと vSAN クラスタをセットアップする際に、ここまでセットアップしてきた

vSAN Witness Appliance を vSAN 監視ホストとして指定します。

vSAN クラスタの設定でも PowerCLI を利用することができます。

PowerCLI で vSAN セットアップをためしてみる。(2 Node 版)

 

そして工夫次第で vSAN Witness Appliance ~ vSAN セットアップまで

PowerCLI スクリプトで自動化できたりします。

 

以上、PowerCLI で vSAN Witness Appliance をセットアップしてみる話でした。

ESXi 上の VM に ESXi をインストールする「Nested ESXi」と呼ばれる使用方法があり、

検証環境や、vSAN Witness Appliance などで利用されています。

Running Nested VMs

 

Nested ESXi は物理マシンへのインストールと同様に DCUI からの設定作業ができるため

通常は、VM コンソールから設定をすることになります。

nested-esxi-vm.png

 

しかし VM であり、しかも最近の ESXi 6.x ではデフォルトで VMware Tools がインストールされます。

そのため Nested ESXi では、ネットワーク設定前であっても

vSphere のレイヤから直接での設定投入ができます。

 

通常、PowerCLI からゲスト OS の設定を変更する場合は Invoke-VMScript を使用しますが、

ScriptType で指定できるインタープリタは PowerShell、Bat、Bash だけなので

ESXi ではスクリプト(コマンド)が実行できません。

 

Invoke-VMScript

https://code.vmware.com/doc/preview?id=6330#/doc/Invoke-VMScript.html

 

そこで、ためしに vSphere Web Services API の GuestOperationsManager にある

GuestProcessManager を利用して esxcli コマンドを実行してみました。

 

GuestProcessManager

https://code.vmware.com/apis/358/vsphere?h=GuestOperationsManager#/doc/vim.vm.guest.ProcessManager.html

 

今回は、下記のようなサンプル スクリプトを作成してみました。

エラー制御などは、あえて一切いれていないので、

実行してみる場合はお好みで改造していただければと・・・

invoke_nested-esxcli.ps1 · GitHub

 

スクリプトの内容は下記のようになっています。

param($ESXiVM, $ESXiUser, $ESXiPass)

 

# 最初に変数設定。

$vm_name = $ESXiVM

$esxi_user = $ESXiUser

$esxi_pass = $ESXiPass

$esxcli_args = $args

 

$vm = Get-VM $vm_name | select -First 1

$vm_id = $vm.Id

$vc_name = $vm.Uid  -replace "^.*@|:.*$",""

$vc = $global:DefaultVIServers | where {$_.Name -eq $vc_name}

 

"ESXi VM Name:" + $vm.Name

"esxcli args: " + $esxcli_args

 

# ESXi の認証情報をセット。

$cred = New-Object VMware.Vim.NamePasswordAuthentication

$cred.Username = $esxi_user

$cred.Password = $esxi_pass

 

# esxcli コマンドをフルパスで指定。

$gps = New-Object VMware.Vim.GuestProgramSpec

$gps.WorkingDirectory = "/tmp"

$gps.ProgramPath = "/bin/esxcli"

$gps.Arguments = $esxcli_args

 

# ここでコマンド実行。

$gom = Get-View $vc.ExtensionData.Content.GuestOperationsManager

$pm = Get-View $gom.ProcessManager

$gos_pid = $pm.StartProgramInGuest($vm_Id, $cred, $gps)

$pm.ListProcessesInGuest($vm_Id, $cred, $gos_pid)

 

実行するときには、まず Nested VM を管理している vCenter に接続しておきます。

PowerCLI> Connect-VIServer <vCenter アドレス>

 

このスクリプトでは、esxcli のオプションを通常どおり指定しやすいように工夫しています。

実行方法は、下記のような感じです。

PowerCLI> .\invoke_nested-esxcli.ps1 <esxcli option> -ESXiVM:<Nested ESXi VM Name> -ESXiUser:<Nested ESXi User Name> -ESXiPass:<Nested ESXi User password>

 

もしくは・・・

PowerCLI> .\invoke_nested-esxcli.ps1 -ESXiVM:<Nested ESXi VM Name> -ESXiUser:<Nested ESXi User Name> -ESXiPass:<Nested ESXi User password> <esxcli option>

 

たとえば「esxcli system hostname set --host ~ --domain ~」の実行は

下記のようになります。

PowerCLI> .\invoke_nested-esxcli.ps1 system hostname set --host hv-n23w --domain go-lab.jp -ESXiVM:hv-n23w -ESXiUser:root -ESXiPass:VMware1!

ESXi VM Name:hv-n23w

esxcli args: system hostname set --host hv-n23w --domain go-lab.jp

 

Name      : esxcli

Pid       : 2278253

Owner     : root

CmdLine   : "/bin/esxcli" system hostname set --host hv-n23w --domain go-lab.jp

StartTime : 2018/04/22 2:52:18

EndTime   :

ExitCode  :

 

 

これだとコマンドの出力結果は取得できないのですが、

Nested ESXi をネットワーク設定して vCenter に登録してしまえば

vCenter 経由で ESXi の設定確認ができるので、うちでは設定投入するだけの利用をしています。

 

ちなみに、今回の環境では下記でした。

  • 物理環境: vCenter 6.5 U1 / ESXi 6.5 U1
  • Nested ESXi: ESXi 6.7
  • PowerCLI 10.0.0 / PowerShell 5.1 / Windows 10

 

以上、PowerCLI から Nested ESXi の esxcli を実行してみる話でした。

vSAN 6.7 がリリースされ、とうとう vSAN も vSphere Client(通称 HTML5 Client)で操作可能になりました。

What’s New with VMware vSAN 6.7 - Virtual Blocks

 

そこで、さっそく HTML5 Client で 2 ノード の vSAN を構成してみました。

 

事前に下記の準備をしてあります。

 

vCenter 6.7 の HTML5 Client です。

vsan67-h5-2node-01.png

 

VMkernel ポートの vSAN Witness トラフィックのタグ(vSAN 監視)が設定されているか、

確認できるようになっています。(設定はまだ esxcli などになるようです)

vsan67-h5-2node-16.png

 

HTML5 Client での 2ノード vSAN の構成。

クラスタの「設定」→「vSAN」→「サービス」の

「構成」ボタンから vSAN を有効化できるようになっています。

vsan67-h5-2node-02.png

 

「2 台のホストの vSAN クラスタ」を選択します。

vsan67-h5-2node-03.png

 

デデュープ(重複排除)および圧縮、暗号化などは有効化せず、そのまま次へ。

vsan67-h5-2node-04.png

 

キャッシュ層、キャパシティ層のディスクを選択します。

vsan67-h5-2node-05.png

 

すでに vCenter に登録してある vSAN Witness Appliance を

監視ホストとして選択します。

vsan67-h5-2node-06.png

 

監視ホストでも、キャッシュ層、キャパシティ層のディスクを選択します。

vsan67-h5-2node-07.png

 

確認画面で「完了」して、タスクが完了するのを待ちます。

vsan67-h5-2node-08.png

 

構成した 2ノード vSAN の様子。

サポートされていないハードウェア(Nested ESXi)で構成しているのでエラーや警告が出ていますが・・・

「サマリー」タブに「vSAN の概要」が表示されています。

vsan67-h5-2node-09.png

 

「健全性」の確認も HTML5 Client でできるようになっています。

ためしに「ストレッチ クラスタ」の様子を見てみました。

vsan67-h5-2node-14.png

 

「設定」タブのメニューをいくつか見てみます。

vsan67-h5-2node-10.png

 

ディスクグループの様子です。

vsan67-h5-2node-11.png

 

フォルト ドメイン が 2つ構成されて、監視ホストが指定されている様子もわかります。

vsan67-h5-2node-12.png

 

ちゃんと 2 ノード vSAN でも HTML5 Client が利用できそうです。

 

以上、HTML5 Client から vSAN の  2 ノードクラスタを構成してみる話でした。

今回は vSphere Docker Volume Service(vDVS)を利用して、

vSAN データストアから Docker Volume を作成してみます。

 

Docker では基本的にコンテナを削除すると一緒にデータも削除されてしまいます。

しかし、Docker  Volume とよばれる仕組みを利用することで

コンテナの削除にかかわらずデータを永続化することができます。

 

そして vSphere 環境での Docker にその永続的なストレージ(Volume)を提供する

Project Hatchway というプロジェクトがあります。

Hatchway では Docker / Kubernetes などに、vSphere のデータストアの仮想ディスクを Volume として提供します。

Project Hatchway by VMware®

 

VMware の Storage Hub にもドキュメントがあります。

 

Introduction to Project Hatchway

https://storagehub.vmware.com/t/vsphere-storage/project-hatchway/

 

それでは vDVS をセットアップしてみます。

vDVS では、Docker ホストになる VM と ESXi との両方での対応が必要です。

  1. ESXi への VIB のインストール。
  2. Docker ホスト(ゲスト OS)への Docker Plugin のインストール。

 

今回の環境。

すでに vCenter 6.5 U1 / ESXi 6.5 U1 の環境を構築ずみです。

 

このクラスタの ESXi は、vSAN / NFS データストアを接続しています。

  • vSAN データストア: vsanDatastore-04
  • NFS データストア: ds-nfs-vmdk-01

vdvs-vsan-01.png

 

ESXi は 2台(hv-n41 / hv-n42)あり、それぞれ VM が1台ずつ(vm41 / vm42)起動しています

vdvs-vsan-02.png

 

今回の ESXi は、6.5 U1 です。

[root@hv-n41:~] vmware -vl

VMware ESXi 6.5.0 build-7388607

VMware ESXi 6.5.0 Update 1

 

Docker ホスト(ゲスト OS)は、Photon OS 2.0 にしました。

root@vm41 [ ~ ]# cat /etc/photon-release

VMware Photon OS 2.0

PHOTON_BUILD_NUMBER=304b817

root@vm41 [ ~ ]# uname -r

4.9.90-1.ph2-esx

 

今回の Docker バージョンは 17.06 です。

root@vm41 [ ~ ]# docker version

Client:

Version:      17.06.0-ce

API version:  1.30

Go version:   go1.8.1

Git commit:   02c1d87

Built:        Thu Oct 26 06:33:23 2017

OS/Arch:      linux/amd64

 

Server:

Version:      17.06.0-ce

API version:  1.30 (minimum version 1.12)

Go version:   go1.8.1

Git commit:   02c1d87

Built:        Thu Oct 26 06:34:46 2017

OS/Arch:      linux/amd64

Experimental: false

 

ESXi への VIB のインストール。

ESXi ホストそれぞれ(今回は 2台)で、VIB をインストールします。

 

vDVS の VIB は、Bintray からダウンロードできます。

最新版は下記の URL から入手できます。

https://bintray.com/vmware/vDVS/VIB/_latestVersion

 

今回は、Version 0.21.1 を利用します。

https://bintray.com/vmware/vDVS/VIB/0.21.1

https://bintray.com/vmware/vDVS/download_file?file_path=VDVS_driver-0.21.1-offline_bundle-7812185.zip

 

VIB のオフラインバンドルは、vSAN データストアに配置しました。

vSAN データストアに osfs-mkdir コマンドでディレクトリを作成して・・・

[root@hv-n41:~] /usr/lib/vmware/osfs/bin/osfs-mkdir /vmfs/volumes/vsanDatastore-04/vib

 

VIB のオフラインバンドル「VDVS_driver-0.21.1-offline_bundle-7812185.zip」を配置してあります。

VIB の名前は「esx-vmdkops-service」になっています。

[root@hv-n41:~] ls /vmfs/volumes/vsanDatastore-04/vib

VDVS_driver-0.21.1-offline_bundle-7812185.zip

[root@hv-n41:~] esxcli software sources vib list -d /vmfs/volumes/vsanDatastore-04/vib/VDVS_driver-0.21.1-offline_bundle-7812185.zip

Name                 Version             Vendor  Creation Date  Acceptance Level  Status

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

esx-vmdkops-service  0.21.c420818-0.0.1  VMWare  2018-02-13     VMwareAccepted    New

 

esxcli でインストールします。

[root@hv-n41:~] esxcli software vib install -d /vmfs/volumes/vsanDatastore-04/vib/VDVS_driver-0.21.1-offline_bundle-7812185.zip

Installation Result

   Message: Operation finished successfully.

   Reboot Required: false

   VIBs Installed: VMWare_bootbank_esx-vmdkops-service_0.21.c420818-0.0.1

   VIBs Removed:

   VIBs Skipped:

 

インストールした VIB の情報です。

[root@hv-n41:~] esxcli software vib get -n esx-vmdkops-service

VMWare_bootbank_esx-vmdkops-service_0.21.c420818-0.0.1

   Name: esx-vmdkops-service

   Version: 0.21.c420818-0.0.1

   Type: bootbank

   Vendor: VMWare

   Acceptance Level: VMwareAccepted

   Summary: [Fling] ESX-side daemon supporting basic VMDK operations requested by a guest

   Description: Executes VMDK operations requested by an in-the-guest application.

   ReferenceURLs:

   Creation Date: 2018-02-13

   Depends: esx-version >= 6.0.0

   Conflicts:

   Replaces:

   Provides:

   Maintenance Mode Required: False

   Hardware Platforms Required:

   Live Install Allowed: True

   Live Remove Allowed: True

   Stateless Ready: False

   Overlay: False

   Tags:

   Payloads: vmdkops

 

hostd を再起動しておきます。

[root@hv-n41:~] /etc/init.d/hostd restart

watchdog-hostd: Terminating watchdog process with PID 67445

hostd stopped.

hostd started.

 

Docker ホスト(ゲスト OS)への Docker Plugin のインストール。

Dcoker ホストそれぞれ(今回は 2台)に、Docker Plugin をインストールします。

 

はじめは、Docker Plugin が登録されていない状態です。

root@vm41 [ ~ ]# docker plugin ls

ID                  NAME                DESCRIPTION         ENABLED

root@vm41 [ ~ ]#

 

Docker Plugin は、Docker Store からインストールします。

root@vm41 [ ~ ]# docker plugin install --grant-all-permissions --alias vsphere vmware/vsphere-storage-for-docker:latest

latest: Pulling from vmware/vsphere-storage-for-docker

05da47b7b6ce: Download complete

Digest: sha256:a20bcdfef99ebf017bf3cabd815f256430bf56d8cb7881048150e7c918e0c4c6

Status: Downloaded newer image for vmware/vsphere-storage-for-docker:latest

Installed plugin vmware/vsphere-storage-for-docker:latest

 

Plugin がインストールされました。

root@vm41 [ ~ ]# docker plugin ls

ID                  NAME                DESCRIPTION                           ENABLED

5bb66ae50bbd        vsphere:latest      VMWare vSphere Docker Volume plugin   true

 

設定ファイルを作成しておきます。

内容は主にログ出力設定ですが、このファイルがなくてもとりあえず vDVS はログ出力します。

cat << EOF > /etc/vsphere-storage-for-docker.conf

{

    "Driver": "vsphere",

    "MaxLogAgeDays": 28,

    "MaxLogFiles": 10,

    "MaxLogSizeMb": 10,

    "LogPath": "/var/log/vsphere-storage-for-docker.log",

    "LogLevel": "info",

    "GroupID": "root"

}

EOF

 

Volume を利用してみる。

1台目の Docker ホスト「vm41」で、Docker Volume を作成してみます。

 

docker volume create コマンドで vsphere ドライバを指定して、ボリュームを作成します。

今回の環境では vSAN と NFS のデータストアがありますが、特にデータストアを作成しない場合は

vSAN データストアにボリュームが作成されました。

root@vm41 [ ~ ]# docker volume create --driver=vsphere --name=vol01 -o size=1gb

vol01

root@vm41 [ ~ ]# docker volume ls

DRIVER              VOLUME NAME

vsphere:latest      vol01@vsanDatastore-04

 

NFS データストアを指定して、ボリュームを作成してみます。

root@vm41 [ ~ ]# docker volume create --driver=vsphere --name=vol02@ds-nfs-vmdk-01 -o size=1gb

vol02@ds-nfs-vmdk-01

root@vm41 [ ~ ]# docker volume ls

DRIVER              VOLUME NAME

vsphere:latest      vol01@vsanDatastore-04

vsphere:latest      vol02@ds-nfs-vmdk-01

 

それぞれのデータストアにファイルが作成されています。

[root@hv-n41:~] ls -l /vmfs/volumes/vsanDatastore-04/dockvols/_DEFAULT/

total 8

-rw-------    1 root     root          4096 Apr 16 16:52 vol01-1d8b22d5cfe8e28a.vmfd

-rw-------    1 root     root           586 Apr 16 16:52 vol01.vmdk

[root@hv-n41:~] ls -l /vmfs/volumes/ds-nfs-vmdk-01/dockvols/_DEFAULT/

total 33436

-rw-------    1 root     root          4096 Apr 16 17:06 vol02-256a299ab1ad11b3.vmfd

-rw-------    1 root     root     1073741824 Apr 16 17:06 vol02-flat.vmdk

-rw-------    1 root     root           558 Apr 16 17:06 vol02.vmdk

 

vSAN データストアに作成された Volume を接続して、コンテナを起動してみます。

コンテナ イメージは Docker Hub オフィシャルの Photon OS のイメージです。

ボリューム「vol01」は、/dir01 ディレクトリにマウントします。

root@vm41 [ ~ ]# docker container run -it -v vol01@vsanDatastore-04:/dir01 photon

root [ / ]# uname -n

e58556770d1b

root [ / ]# cat /etc/photon-release

VMware Photon OS 2.0

PHOTON_BUILD_NUMBER=304b817

 

コンテナの中での df コマンドで、ボリュームが接続されていことがわかります。

root [ / ]# df -h

Filesystem                                      Size  Used Avail Use% Mounted on

overlay                                          16G  420M   15G   3% /

tmpfs                                           122M     0  122M   0% /dev

tmpfs                                           122M     0  122M   0% /sys/fs/cgroup

/dev/disk/by-path/pci-0000:03:00.0-scsi-0:0:1:0 976M  2.5M  973M   1% /dir01

/dev/root                                        16G  420M   15G   3% /etc/resolv.conf

shm                                              64M     0   64M   0% /dev/shm

tmpfs                                           122M     0  122M   0% /sys/firmware

 

ためしに、Volume をマウントしたディレクトリ /dir01 に適当なデータを書き込んでおきます。

root [ / ]# echo "yo-soro-!" > /dir01/test.f

root [ / ]# cat /dir01/test.f

yo-soro-!

 

コンテナを抜けて、Docker ホストに戻ります。

Volume は、Docker ホストに /dev/sdb として接続されています。

root@vm41 [ ~ ]# LANG=C lsblk

NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT

sda      8:0    0   16G  0 disk

|-sda1   8:1    0    3M  0 part

`-sda2   8:2    0   16G  0 part /

sdb      8:16   0    1G  0 disk /var/lib/docker/plugins/5bb66ae50bbdd237a3205a6051e6f51c88042f1a71c44e49170fef601d9ab9ab/propagated-mount/vol01@vsanDatastore-04

sr0     11:0    1 1024M  0 rom

 

VM から見ても、Docker Volume にあたる「ハード ディスク 2」が

vSAN データストアにあることがわかります。

「仮想マシン ストレージ ポリシー」は Volume 作成時に

指定していないので空欄になっています。

vdvs-vsan-03.png

 

別の Docker ホストでの Volume 利用。

コンテナを削除しても、Volume が消えない様子を確認してみます。

 

まず、これまで Volume を利用していた Docker コンテナを削除します。

root@vm41 [ ~ ]# docker ps

CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES

e58556770d1b        photon              "/bin/bash"         11 minutes ago      Up 11 minutes                           determined_khorana

root@vm41 [ ~ ]# docker container rm -f e58556770d1b

e58556770d1b

root@vm41 [ ~ ]# docker ps

CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES

root@vm41 [ ~ ]#

 

Docker ホストの VM から、Volume にあたる「ハード ディスク 2」が切断されました。

vm41 には、「ハード ディスク 1」だけが残っています。

vdvs-vsan-04.png

 

そして、別の ESXi で起動している Docker ホストで

先ほどの Volume「vol01」を接続したコンテナを起動してみます。

Docker ホスト「vm42」でも、vDVS の Docker Plugin はインストールずみです。

root@vm42 [ ~ ]# docker plugin ls

ID                  NAME                DESCRIPTION                           ENABLED

3e561e744610        vsphere:latest      VMWare vSphere Docker Volume plugin   true

 

この Docker ホストでも、vm41 で作成した Volume が見えます。

root@vm42 [ ~ ]# docker volume ls

DRIVER              VOLUME NAME

vsphere:latest      vol01@vsanDatastore-04

vsphere:latest      vol02@ds-nfs-vmdk-01

 

Volume「vol01」を接続して、コンテナを起動します。

Volume はコンテナとは独立してデータが永続化されているので、

先ほど Volume に作成したファイルが残っています。

root@vm42 [ ~ ]# docker container run -it -v vol01@vsanDatastore-04:/dir01 photon

Unable to find image 'photon:latest' locally

latest: Pulling from library/photon

d3603a6287f0: Pull complete

Digest: sha256:9cdad7d78710eed3dd4fc5e565bf783aec99ece689d8ab9771b629fd4e5d0ed1

Status: Downloaded newer image for photon:latest

root [ / ]# uname -n

cd2ba7d55444

root [ / ]# cat /dir01/test.f

yo-soro-!

 

このように vDVS では、コンテナで利用するデータを永続化して、

別の ESXi で起動する Docker ホスト(の VM)でもデータを利用することができます。

そして VMFS / NFS / vSAN といった、どのデータストアでも同様に Docker Volume を作成できます。

 

以上、vDVS を使用してみる話でした。

ひきつづき、PowerCLI 10.0 で vRealize Operations Manager(vROps)6.6.1 から情報を取得してみます。

今回は、PowerCLI でどのような vSAN の情報を取得できるのか

(どのようなメトリックが取得できるのか)を確認してみます。

 

PowerCLI での vROps への接続については、これまでの投稿をどうぞ。

PowerCLI で vROps に接続してみる。

 

まず vROps のリソースから情報収集で利用されるアダプタの種類を抽出してみると、

いかにも vSAN にかかわるもの「VirtualAndPhysicalSANAdapter」があります。

PowerCLI> Get-OMResource | select AdapterKind -Unique | Sort-Object AdapterKind

 

AdapterKind

-----------

Container

EP Ops Adapter

OPENAPI

PythonRemediationVcenterAdapter

VCACAdapter

vCenter Operations Adapter

VirtualAndPhysicalSANAdapter

VMWARE

vRealizeOpsMgrAPI

 

 

そしてすべてのリソースから、そのアダプタをもとに vSAN 特有のものと思われるリソースの種類を抽出してみます。

※通常の仮想マシンや仮想ディスクの情報については、今回は省略します。

PowerCLI> Get-OMResource -AdapterKind VirtualAndPhysicalSANAdapter | select ResourceKind -Unique | Sort-Object ResourceKind

 

ResourceKind

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

CacheDisk

CapacityDisk

VirtualAndPhysicalSANAdapter Instance

VirtualSANDCCluster

VirtualSANDiskGroup

VirtualSANFaultDomain

VirtualSANWitnessHost

vSAN World

 

 

このアダプタに関する性能情報のキーを取得してみます。

982 のメトリックがあるようです。

PowerCLI> $stat_keys = Get-OMResource -AdapterKind VirtualAndPhysicalSANAdapter | Get-OMStatKey | Sort-Object ResourceKind,Name

PowerCLI> $stat_keys.Count

982

 

最初の 10件だけ select して、様子を見てみます。

PowerCLI> $stat_keys | select -First 10 | ft -AutoSize

 

Name                           Unit ResourceKind Description

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

badge|alert_count_critical          CacheDisk    Alert Count Critical

badge|alert_count_immediate         CacheDisk    Alert Count Immediate

badge|alert_count_info              CacheDisk    Alert Count Info

badge|alert_count_warning           CacheDisk    Alert Count Warning

badge|anomaly                       CacheDisk    Anomaly

badge|capacityRemaining        %    CacheDisk    Capacity Remaining

badge|capacityRemaining_whatif %    CacheDisk    Capacity Remaining with committed projects

badge|compliance                    CacheDisk    Compliance

badge|density                       CacheDisk    Density

badge|density_whatif                CacheDisk    Density with committed projects

 

 

ちなみに上記のうちの1件に含まれるプロパティをすべて表示して様子をみると、下記のようになっています。

PowerCLI> $stat_keys | select -First 1 *

 

ExtensionData : VMware.VimAutomation.VROps.Views.ResourceTypeAttribute

Name          : badge|alert_count_critical

Unit          :

Description   : Alert Count Critical

ResourceKind  : CacheDisk

AdapterKind   : VirtualAndPhysicalSANAdapter

Client        : VMware.VimAutomation.vROps.Impl.V1.OMClientImpl

Uid           : /OMServer=admin@vrops01.go-lab.jp:443/AdapterKind=VirtualAndPhysicalSANAdapter/ResourceKind=CacheDisk/O

                MStatKey=badge|alert_count_critical/

 

 

あまりに多いので、CSV でエクスポートしてみました。

リソースの種類(ResourceKind)ごとに、取得できる性能情報(Name)が異なることがわかります。

PowerCLI> $stat_keys | select ResourceKind,Name,Unit,Description | Export-Csv -Encoding UTF8 -NoTypeInformation -Path .\vrops_vsan_stat-keys.csv

vrops_vsan_stat-keys.csv · GitHub

 

前のコマンドラインでは、流れの都合で変数「$stat_keys」から CSV エクスポートしていますが、

実行した内容は下記のような内容です。

PowerCLI> Get-OMResource -AdapterKind VirtualAndPhysicalSANAdapter | Get-OMStatKey | Sort-Object ResourceKind,Name | select ResourceKind,Name,Unit,Description | Export-Csv -Encoding UTF8 -NoTypeInformation -Path .\vrops_vsan_stat-keys.csv

 

ここで取得した ResourceKind や Name をもとにして、

下記の投稿のように個々のリソースについての性能情報を取得できます。

PowerCLI で vROps から vSAN ディスクグループの情報を取得してみる。

 

vROps で取得できる性能情報は多いので、PowerCLI を利用することで

効率よく確認対象の精査をする工夫ができるのではないかと思います。

 

以上、PowerCLI で vROps からどのような情報が取得できるか確認してみる話でした。

PowerCLI 10.0 で、vRealize Operations Manager(vROps)から

vSAN ディスクグループのメトリック情報を取得してみます。

 

vROps は、vSAN にかかわる情報も収集していて、

たとえば下記のように vSAN ディスクグループの性能情報を確認することができます。

vrops-vsan-01.png

 

PowerCLI で vROps に接続することで、同様の情報をコマンド実行で取得することができます。

 

まず、vROps に接続しておきます。(前回の投稿より)

PowerCLI で vROps に接続してみる。

 

あわせて、vCenter Server (うちの vCenter アドレスは vc-sv01.go-lab.jp)にも接続しておきます。

PowerCLI> Connect-VIServer vc-sv01.go-lab.jp -Force

 

今回は、vSAN ディスクグループの情報を取得してみます。

vSAN クラスタのホストから・・・

PowerCLI> Get-Cluster vsan-cluster-01 | Get-VMHost | Sort-Object Name | select Name

 

Name

----

hv-i21.go-lab.jp

hv-i22.go-lab.jp

hv-i23.go-lab.jp

hv-i24.go-lab.jp

hv-i25.go-lab.jp

hv-i26.go-lab.jp

 

 

1台の vSAN ディスクグループを選んで見ます。

PowerCLI> Get-VMHost hv-i21.go-lab.jp | Get-VsanDiskGroup | fl Name,DiskGroupType

 

Name          : Disk group (0100000000424631335f303036315f434233385f323530300053414d53554e)

DiskGroupType : AllFlash

 

 

ディスクグループのリソース情報が収集できています。

PowerCLI> Get-OMResource -ResourceKind VirtualSANDiskGroup -Name $dg.Name

 

 

Name                         Health  ResourceKind    Description

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

Disk group (0100000000424... Green   VirtualSANDi...

 

 

 

PowerCLI> Get-OMResource -ResourceKind VirtualSANDiskGroup -Name $dg.Name | select Name,AdapterKind,ResourceKind,Status,Health,HealthValue

 

Name         : Disk group (0100000000424631335F303036315F434233385F323530300053414D53554E)

AdapterKind  : VirtualAndPhysicalSANAdapter

ResourceKind : VirtualSANDiskGroup

Status       : DataReceiving

Health       : Green

HealthValue  : 100

 

 

vSAN ディスクグループでは、下記のような情報を取得されていることがわかります。

PowerCLI> Get-OMResource -ResourceKind VirtualSANDiskGroup -Name $dg.Name | Get-OMStat | select key -Unique | Sort-Object key

 

Key

---

badge|anomaly

badge|capacityRemaining

badge|compliance

badge|efficiency

badge|efficiency_classic

badge|efficiency_state

badge|fault

badge|health

badge|health_classic

badge|health_state

badge|risk

badge|risk_classic

badge|risk_state

badge|timeRemaining

badge|timeRemaining_whatif

badge|workload

Congestion|compCongestion

Congestion|iopsCongestion

Congestion|logCongestion

Congestion|memCongestion

Congestion|slabCongestion

Congestion|ssdCongestion

DiskI/O|busResets

DiskI/O|commandsAborted

DiskI/O|deviceLatency

DiskI/O|deviceReadLatency

DiskI/O|deviceWriteLatency

DiskI/O|errors

DiskI/O|iopsRead

DiskI/O|iopsWrite

DiskI/O|latencyAvgRead

DiskI/O|latencyAvgWrite

DiskI/O|maxIopsRead

DiskI/O|maxIopsWrite

DiskI/O|readCount

DiskI/O|throughputRead

DiskI/O|throughputWrite

DiskI/O|writeCount

DiskSpace|actual.capacity

DiskSpace|actual.capacity.normalized

DiskSpace|base.demand

diskspace|capacity

diskspace|capacityRemaining

diskspace|capacityRemaining_min

DiskSpace|capacityRemainingValue

DiskSpace|capacityUsage

DiskSpace|capacityUsed

DiskSpace|idletimepercent

DiskSpace|object.capacity

DiskSpace|object.capacity.not.normalized

DiskSpace|object.capacity.with.ha

DiskSpace|object.demand

DiskSpace|object.demand.percent

DiskSpace|object.demand.with.size.recommendation

DiskSpace|object.demand.without.size.recommendation

DiskSpace|oversized

DiskSpace|size.recommendation

diskspace|timeRemaining

diskspace|timeRemaining_whatif

DiskSpace|underusedpercent

diskspace|workload

ReadCache|rateCapacity

ReadCacheRate|actual.capacity

ReadCacheRate|actual.capacity.normalized

ReadCacheRate|object.capacity

ReadCacheRate|object.capacity.not.normalized

ReadCacheRate|object.capacity.with.ha

summary|capacityRemaining_min

summary|idle

summary|poweredOff

summary|poweredOffTimePercent

summary|timeRemaining

summary|timeRemaining_whatif

summary|utilization.range

System Attributes|active_alarms

System Attributes|active_ki_alarms

System Attributes|alert_count_critical

System Attributes|alert_count_immediate

System Attributes|alert_count_info

System Attributes|alert_count_warning

System Attributes|all_metrics

System Attributes|availability

System Attributes|change_index

System Attributes|child_active_alarms

System Attributes|child_active_ki_alarms

System Attributes|child_all_metrics

System Attributes|child_ki_metrics

System Attributes|child_new_alarms

System Attributes|health

System Attributes|ki_metrics

System Attributes|new_alarms

System Attributes|self_alert_count

System Attributes|total_alarms

System Attributes|total_alert_count

WriteBuffer|actual.capacity

WriteBuffer|actual.capacity.normalized

WriteBuffer|base.demand

WriteBuffer|capacityRemaining

WriteBuffer|capacityRemaining_min

WriteBuffer|capacityRemainingValue

WriteBuffer|idletimepercent

WriteBuffer|ioCountWbRead

WriteBuffer|ioCountWbWrite

WriteBuffer|iopsWbRead

WriteBuffer|iopsWbWrite

WriteBuffer|latencyWbRead

WriteBuffer|latencyWbWrite

WriteBuffer|object.capacity

WriteBuffer|object.capacity.not.normalized

WriteBuffer|object.capacity.with.ha

WriteBuffer|object.demand

WriteBuffer|object.demand.percent

WriteBuffer|object.demand.with.size.recommendation

WriteBuffer|object.demand.without.size.recommendation

WriteBuffer|oversized

WriteBuffer|size.recommendation

WriteBuffer|timeRemaining

WriteBuffer|timeRemaining_whatif

WriteBuffer|underusedpercent

WriteBuffer|Usage

WriteBuffer|Used

WriteBuffer|wbFreePct

WriteBuffer|wbSize

WriteBuffer|workload

 

 

たとえば、下記のように 書き込みバッファ容量の推奨値を取得したりできます。

PowerCLI> Get-OMResource -ResourceKind VirtualSANDiskGroup -Name $dg.Name | Get-OMStat -Key "WriteBuffer|size.recommendation" | Sort-Object Time -Descending | select Key,Time,Value -First 10

 

Key                             Time                      Value

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

WriteBuffer|size.recommendation 2018/04/04 21:02:05 17542670336

WriteBuffer|size.recommendation 2018/04/03 21:04:27 18549729280

WriteBuffer|size.recommendation 2018/04/02 21:02:11 18654631936

WriteBuffer|size.recommendation 2018/04/01 21:04:56 19039205376

WriteBuffer|size.recommendation 2018/03/31 21:01:43 18871312384

WriteBuffer|size.recommendation 2018/03/30 21:04:43 17880637440

WriteBuffer|size.recommendation 2018/03/29 21:02:42 17377789952

WriteBuffer|size.recommendation 2018/03/28 21:05:27 17070935040

WriteBuffer|size.recommendation 2018/03/27 21:02:16 17010818048

WriteBuffer|size.recommendation 2018/03/26 21:00:16 16274199552

 

 

この情報は、取得期間を絞ったりすることもできます。

PowerCLI> Get-OMResource -ResourceKind VirtualSANDiskGroup -Name $dg.Name | Get-OMStat -Key "WriteBuffer|size.recommendation" -Start "2018/03/01" -To "2018/03/31" | select Time,Value

 

Time                      Value

----                      -----

2018/03/01 21:02:09 19482898432

2018/03/02 21:03:40 18346463232

2018/03/03 21:05:10 16553049088

2018/03/04 21:02:39 15175520256

2018/03/05 21:04:25 16046277632

2018/03/06 21:01:25 16615967744

2018/03/07 21:03:26 16375300096

2018/03/08 21:00:15 15958652928

2018/03/09 21:04:59 15831619584

2018/03/10 21:01:44 16785255424

2018/03/11 21:03:59 17555458048

2018/03/12 21:00:44 17643444224

2018/03/13 21:03:15 17892603904

2018/03/14 21:00:30 17919207424

2018/03/15 21:02:00 18216976384

2018/03/16 21:03:30 18676643840

2018/03/17 21:05:01 18532560896

2018/03/18 21:01:47 17640730624

2018/03/19 21:03:32 15869313024

2018/03/20 21:00:48 16326699008

2018/03/21 21:00:45 16425305088

2018/03/22 21:02:45 16436318208

2018/03/23 21:04:45 15822150656

2018/03/24 21:01:46 15301784576

2018/03/25 21:03:31 15560028160

2018/03/26 21:00:16 16274199552

2018/03/27 21:02:16 17010818048

2018/03/28 21:05:27 17070935040

2018/03/29 21:02:42 17377789952

2018/03/30 21:04:43 17880637440

 

 

このように情報取得することで、vROps で確認できる性能情報を

PowerShell で集計できるようになります。

定期的な性能レポート作成などでも活用できそうな気がします。

 

以上、vROps から PowerCLI で情報取得してみる話でした。

つづくかもしれない。

PowerCLI 10.0 で、vRealize Operations Manager(vROps)に接続してみます。

 

今回の vROps のホスト名は、vrops01.go-lab.jp で、バージョンは 6.6.1 です。

vrops661-01.png

 

情報収集対象の vCenter Server は vROps に登録ずみです。

vrops661-02.png

 

今回の PowerCLI モジュールのバージョンです。

PowerCLI 10.0 では、下記の vROps むけモジュールがあります。

ちなみに Linux での PowerCLI にもコマンドは含まれていますが、まだ対応はしていないようです。

(今回は Windows 10 で実行しています)

PowerCLI> Get-Command -Module VMware.VimAutomation.vROps | Sort-Object Name | select Source,Version,Name

 

Source                     Version        Name

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

VMware.VimAutomation.vROps 10.0.0.7893921 Connect-OMServer

VMware.VimAutomation.vROps 10.0.0.7893921 Disconnect-OMServer

VMware.VimAutomation.vROps 10.0.0.7893921 Get-OMAlert

VMware.VimAutomation.vROps 10.0.0.7893921 Get-OMAlertDefinition

VMware.VimAutomation.vROps 10.0.0.7893921 Get-OMAlertSubType

VMware.VimAutomation.vROps 10.0.0.7893921 Get-OMAlertType

VMware.VimAutomation.vROps 10.0.0.7893921 Get-OMRecommendation

VMware.VimAutomation.vROps 10.0.0.7893921 Get-OMResource

VMware.VimAutomation.vROps 10.0.0.7893921 Get-OMStat

VMware.VimAutomation.vROps 10.0.0.7893921 Get-OMStatKey

VMware.VimAutomation.vROps 10.0.0.7893921 Get-OMUser

VMware.VimAutomation.vROps 10.0.0.7893921 Get-vROpsCommand

VMware.VimAutomation.vROps 10.0.0.7893921 Set-OMAlert

 

 

これは Get-vROpsCommand でも確認できます。

PowerCLI> Get-vROpsCommand | Sort-Object Name | select Source,Version,Name

 

Source                     Version        Name

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

VMware.VimAutomation.vROps 10.0.0.7893921 Connect-OMServer

VMware.VimAutomation.vROps 10.0.0.7893921 Disconnect-OMServer

VMware.VimAutomation.vROps 10.0.0.7893921 Get-OMAlert

VMware.VimAutomation.vROps 10.0.0.7893921 Get-OMAlertDefinition

VMware.VimAutomation.vROps 10.0.0.7893921 Get-OMAlertSubType

VMware.VimAutomation.vROps 10.0.0.7893921 Get-OMAlertType

VMware.VimAutomation.vROps 10.0.0.7893921 Get-OMRecommendation

VMware.VimAutomation.vROps 10.0.0.7893921 Get-OMResource

VMware.VimAutomation.vROps 10.0.0.7893921 Get-OMStat

VMware.VimAutomation.vROps 10.0.0.7893921 Get-OMStatKey

VMware.VimAutomation.vROps 10.0.0.7893921 Get-OMUser

VMware.VimAutomation.vROps 10.0.0.7893921 Get-vROpsCommand

VMware.VimAutomation.vROps 10.0.0.7893921 Set-OMAlert

 

 

では vROps に接続してみます。

ここで対話的にユーザ / パスワードを入力します。

PowerCLI> Connect-OMServer -Server vrops01.go-lab.jp

 

接続されたことが確認できます。

今回は vROps のローカルユーザで接続したので AuthSource が空欄ですが、

vCenter のユーザで接続すると、ここに vROps に登録した vCenter の名前が入ります。

PowerCLI> $global:DefaultOMServers | fl Name,IsConnected,User,AuthSource

 

Name        : vrops01.go-lab.jp

IsConnected : True

User        : admin

AuthSource  :

 

 

これで vROps のリソース情報が見られるようになります。

PowerCLI> (Get-OMResource).Count

260

PowerCLI> Get-OMResource | group ResourceKind | select Count,Name | Sort-Object Name

 

Count Name

----- ----

    3 AIM Plugin

    1 BusinessService

    7 CacheDisk

   11 CapacityDisk

    7 ClusterComputeResource

    1 ContainerAdapterInstance

    1 Datacenter

   11 Datastore

    2 DatastoreFolder

   23 DistributedVirtualPortgroup

    1 Enterprise

    1 ENTITYSTATUS

    2 Environment

    1 EP Ops Adapter Instance

    4 EP Ops Adapter Resources Group

   18 HostSystem

    2 Licensing

    1 OPENAPI Adapter Instance

    1 Operating Systems World

    1 PythonRemediationVcenterAdapter Instance

    1 Remote Checks World

    4 ResourcePool

    1 Tier

    1 Universe

    1 vCenter Operations Adapter Instance

    1 vC-Ops-Admin-UI

    1 vC-Ops-Analytics

    1 vC-Ops-CaSA

    1 vC-Ops-Cluster

    1 vC-Ops-Collector

    1 vC-Ops-Controller

    1 vC-Ops-Fsdb

    1 vC-Ops-Node

    1 vC-Ops-Persistence

    1 vC-Ops-Product-UI

    1 vC-Ops-Self-Monitoring

    1 vC-Ops-Suite-API

    1 vC-Ops-Watchdog

    1 VirtualAndPhysicalSANAdapter Instance

   90 VirtualMachine

    4 VirtualSANDCCluster

   11 VirtualSANDiskGroup

    4 VirtualSANFaultDomain

    2 VirtualSANWitnessHost

    4 VM Entity Status

   18 VMFolder

    1 VMwareAdapter Instance

    2 VmwareDistributedVirtualSwitch

    1 vRealizeOpsMgrAPI Adapter Instance

    1 vSAN World

    1 vSphere World

 

 

PowerCLI> Get-OMResource -ResourceKind VirtualMachine | select -Last 5

 

Name                         Health  ResourceKind    Description

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

vm01                         Green   VirtualMachine

vrops01                      Green   VirtualMachine

esxi65-template              Green   VirtualMachine

nsx-mgr01                    Green   VirtualMachine

vc-sv01                      Green   VirtualMachine

 

 

個人的には、コマンドラインからメトリック情報を収集する場合などには

REST API よりも PowerCLI の方がデータを扱いやすいかなと思います・・・

 

つづく。

vRealize Network Insight(vRNI)は NSX や vSphere などで

ネット―ワーク仮想化された環境を可視化するツールです。

 

vRNI では過去の特定の時点にさかのぼって情報を確認することができます。

ネットワーク構成や、トラフィックに関するメトリックだけでなく、

実は仮想マシン(VM)の構成情報なども確認できたりします。

 

たとえば、

「仮想マシンで設定ミスがあって修正はしたものの、

 ある事件があった時点での構成はどうだったか確認したい」ようなケースがあるとします。

 

今回は、下記の構成を変更した環境を例として vRNI を見てみます。

  • 複数ある vNIC に、間違って同じポートグループを設定していたものを修正した。
  • 仮想マシンに設定している OS の種類を、事情により
    「Red Hat Enterprise Linux 7」から「Oracle Linux 7」に変更した。

 

vRNI では、NSX のネットワーク構成だけでなく、

上記のような VM 自体についての構成情報も確認することができます。

 

vRNI で VM の構成情報を確認してみる。

例として「db11」という VM を検索して、その構成情報を表示してみました。

この状態は すでに設定を変更して、期待どおりの状態です。

vrni-vm-check-01.png

 

たとえば、3時間前の VM の構成情報はどうだったのか確認したいということであれば、

「Now」のあたりをクリックしてタイム スライダーを表示し、カーソル(今は 7:55)を3時間前に移動します。

vrni-vm-check-02.png

 

そうすると、その時間にさかのぼって・・・

vrni-vm-check-02a.png

 

3時間前(3 hr ago)の情報を確認することができます。

この時間では、まだ OS が「Red Hat Enterprise Linux ~」で、

2 つの vNIC が間違って同じネットワーク(ポートグループ)に接続されていたことがわかります。

vrni-vm-check-03.png

 

vROps で VM の構成情報を確認してみる。

一方、同様の情報を確認できるツールとして vRealize Operations Manager (vROps)もあります。

 

vROps でも同様に、VM「db11」の情報を検索して表示してみます。

 

たとえば下記のように VM の情報を表示したり・・・

vrops-vm-check-01.png

 

VM に関連するオブジェクトを表示したりできます。

(今回のケースでの、接続ポートグループの情報はあります)

vrops-vm-check-02.png

 

しかし vROps では過去にさかのぼった構成情報を確認するのが困難なケースがあります。

環境構成を可視化をするという点では、やはり可視化専用ツールというだけあり vRNI の方が見やすいと思います。

 

ただし vRNI / vROps はどちらも、全く時差がなく情報が反映されるわけではなく、

おなじ VM についての情報でも、パラメータごとに反映への時差があることもあります。

そのため厳密な調査にはイベント情報やログの参照が必要になるとは思いますが、

それでも環境確認やトラブルシュートをするうえでは便利ではないかと思います。

 

以上、vRNI で過去の VM 構成を見てみる話でした。

vSAN には、iSCSI Target を提供する機能があります。

これは物理マシンにブロック デバイスを提供する目的の機能のようで、

下記の KB によると、物理マシンの Oracle RAC でも利用してよいようです。

 

vSAN 6.5 iSCSI デバイスを使用するためのベスト プラクティス (2151966)

https://kb.vmware.com/s/article/2151966

 

そこで、ためしに Oracle Linux 7 から vSAN の iSCSI Target に接続してみました。

今回は機能確認のために仮想マシンの Linux から接続していますが、

現状では、仮想マシンの Oracle RAC は vSAN iSCSI Target のサポート対象外です。

vSAN で仮想マシンで RAC を構築する場合は、以前に投稿した(下記)ように、

共有ディスクは VMDK ファイルを共有する方式になります。(厳密な手順ではありませんので、参考まで)

PowerCLI で vSphere / vSAN 環境での Oracle RAC むけ VM を設定してみる。(2 Node 構成)

 

それでは iSCSI Target を構成して、Linux OS から接続してみます。

 

vSAN iSCSI Target の準備。

iSCSI Target は vSphere Web Client で構成できますが、今回も PowerCLI 10.0(Linux の)を利用します。

 

クラスタでは vSAN / iSCSI Target のサービスを有効にします。

デフォルトのポートは vmk1 を設定しています。

PS /home/gowatana> Get-VsanClusterConfiguration vsan-cluster-02 | Set-VsanClusterConfiguration -IscsiTargetServiceEnabled:$true  -DefaultIscsiNetworkInterface vmk1

 

iSCSI Target のサービスが有効になりました。

PS /home/gowatana> Get-Cluster vsan-cluster-02 | Get-VsanClusterConfiguration | select VsanEnabled,IscsiTargetServiceEnabled | fl

 

VsanEnabled               : True

IscsiTargetServiceEnabled : True

 

 

iSCSI Target を作成します。

PS /home/gowatana> Get-Cluster vsan-cluster-02 | New-VsanIscsiTarget -Name vsan-rac-target-01

 

IQN は、今回は自動生成されたものを使用します。LUN はまだゼロです。

PS /home/gowatana> Get-VsanIscsiTarget -Cluster vsan-cluster-02 -Name vsan-rac-target-01 | select IscsiQualifiedName,NetworkInterface,NumLuns | fl

 

IscsiQualifiedName : iqn.1998-01.com.vmware.52ecb04fd04ccfd2-0385259a575100b2

NetworkInterface   : vmk1

NumLuns            : 0

 

 

今回の環境では、iSCSI Initiator は vSAN クラスタに所属している ESXi ホストの vmk1 の IP アドレス宛に接続することになります。

PS /home/gowatana> Get-Cluster vsan-cluster-02 | Get-VMHost | Get-VMHostNetworkAdapter -Name vmk1 | select Name,VMHost,IP,SubnetMask | Sort-Object VMHost

 

Name VMHost           IP             SubnetMask

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

vmk1 hv-n11.go-lab.jp 192.168.51.211 255.255.255.0

vmk1 hv-n12.go-lab.jp 192.168.51.212 255.255.255.0

vmk1 hv-n13.go-lab.jp 192.168.51.213 255.255.255.0

 

 

Target に LUN を作成します。今回は 3つ作成します。

PS /home/gowatana> New-VsanIscsiLun -Target vsan-rac-target-01 -Name lun0 -CapacityGB 30

PS /home/gowatana> New-VsanIscsiLun -Target vsan-rac-target-01 -Name lun1 -CapacityGB 30

PS /home/gowatana> New-VsanIscsiLun -Target vsan-rac-target-01 -Name lun2 -CapacityGB 30

 

Target の LUN 数が 3になりました。

PS /home/gowatana> Get-VsanIscsiTarget -Cluster vsan-cluster-02 -Name vsan-rac-target-01 | select IscsiQualifiedName,NetworkInterface,NumLuns | fl

 

IscsiQualifiedName : iqn.1998-01.com.vmware.52ecb04fd04ccfd2-0385259a575100b2

NetworkInterface   : vmk1

NumLuns            : 3

 

 

iSCSI Initiator Group を作成して、Target への接続を許可する Initiator の IQN を追加します。

今回は、iSCSI Initiator (クライアントとなる Linux 側)の IQN をあらかじめ決定しておきます。

PS /home/gowatana> Get-Cluster vsan-cluster-02 | New-VsanIscsiInitiatorGroup -Name iqn-rac-group-01

PS /home/gowatana> Get-Cluster vsan-cluster-02 | Get-VsanIscsiInitiatorGroup -Name iqn-rac-group-01 | Set-VsanIscsiInitiatorGroup -AddInitiator iqn.1988-12.com.oracle:db11

PS /home/gowatana> Get-Cluster vsan-cluster-02 | Get-VsanIscsiInitiatorGroup -Name iqn-rac-group-01 | Set-VsanIscsiInitiatorGroup -AddInitiator iqn.1988-12.com.oracle:db12

 

Initiator Group に IQN が登録されました。

PS /home/gowatana> Get-Cluster vsan-cluster-02 | Get-VsanIscsiInitiatorGroup -Name iqn-rac-group-01 | select InitiatorName

 

InitiatorName

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

{iqn.1988-12.com.oracle:db11, iqn.1988-12.com.oracle:db12}

 

 

Target に Initiator Group を関連付けます。

PS /home/gowatana> Get-Cluster vsan-cluster-02 | Get-VsanIscsiTarget -Name vsan-rac-target-01 | New-VsanIscsiInitiatorGroupTargetAssociation -InitiatorGroup iqn-rac-group-01

 

vSphere Web Client で見ると、下記のように設定してきた内容が反映されています。

Target には、作成したとおりの LUN が接続されています。

今回はふれていませんが、GUI から見ると仮想マシンと同様にストレージ ポリシーを利用できることもわかりやすいと思います。

vsan-iscsi-01.png

 

Initiator Group も Target に割り当てられています。

vsan-iscsi-02.png

 

iSCSI Target に接続するクライアント。

今回は、物理マシンのかわりに(製品としてはサポート外ですが)仮想マシンから接続してみます。

 

Oracle Linux 7 のゲストを 2台用意しています。

PS /home/gowatana> Get-VM db1? | Get-VMGuest | select VM,State,OSFullName | Sort-Object VM

 

VM     State OSFullName

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

db11 Running Oracle Linux 7 (64-bit)

db12 Running Oracle Linux 7 (64-bit)

 

 

vNIC はネットワークセグメントごとに 1つずつ用意しています。

Linux では Bondig を構成していません。

PS /home/gowatana> Get-VM db1? | Get-NetworkAdapter | select Parent,Name,NetworkName | Sort-Object Parent,Name

 

Parent Name              NetworkName

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

db11   Network adapter 1 dvpg-vds01-vlan-1011

db11   Network adapter 2 dvpg-vds01-vlan-0041

db11   Network adapter 3 dvpg-vds01-vlan-0051

db12   Network adapter 1 dvpg-vds01-vlan-1011

db12   Network adapter 2 dvpg-vds01-vlan-0041

db12   Network adapter 3 dvpg-vds01-vlan-0051

 

 

ゲスト OS です。

[root@db11 ~]# cat /etc/oracle-release

Oracle Linux Server release 7.4

 

それぞれ、iSCSI 接続前は下記のようにディスクを認識しています。

[root@db11 ~]# lsscsi

[2:0:0:0]    disk    VMware   Virtual disk     2.0   /dev/sda

[2:0:1:0]    disk    VMware   Virtual disk     2.0   /dev/sdb

[3:0:0:0]    cd/dvd  NECVMWar VMware SATA CD00 1.00  /dev/sr0

[root@db11 ~]# lsblk -l /dev/sd?

NAME        MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT

sda           8:0    0   16G  0 disk

sda1          8:1    0    1G  0 part /boot

sda2          8:2    0   15G  0 part

ol-root     249:0    0 13.4G  0 lvm  /

ol-swap     249:1    0  1.6G  0 lvm  [SWAP]

sdb           8:16   0   20G  0 disk

vg01-data01 249:2    0   20G  0 lvm  /u01

 

iSCSI Initiator の準備。(Linux OS)

 

iSCSI Initiator をインストールします。

[root@db11 ~]# yum install -y -q iscsi-initiator-utils

[root@db11 ~]# rpm -q iscsi-initiator-utils

iscsi-initiator-utils-6.2.0.874-4.0.1.el7.x86_64

 

IQN を Initiator Group に事前登録したものに変更しておきます。

[root@db11 ~]# cat /etc/iscsi/initiatorname.iscsi

InitiatorName=iqn.1988-12.com.oracle:89b502eafaa

[root@db11 ~]# echo 'InitiatorName=iqn.1988-12.com.oracle:db11' > /etc/iscsi/initiatorname.iscsi

[root@db11 ~]# cat /etc/iscsi/initiatorname.iscsi

InitiatorName=iqn.1988-12.com.oracle:db11

 

Initiator のサービスを起動しておきます。

(ただ、実は後で自動起動されます)

[root@db11 ~]# systemctl enable iscsid

Created symlink from /etc/systemd/system/multi-user.target.wants/iscsid.service to /usr/lib/systemd/system/iscsid.service.

[root@db11 ~]# systemctl start iscsid

[root@db11 ~]# systemctl is-active iscsid

active

 

iSCSI Target への接続。

まず、vSAN クラスタ内のホストのうち 1台に接続してみます。

iSCSI Target のアドレスで discovery してから login します。

[root@db11 ~]# iscsiadm -m discovery -t sendtargets -p 192.168.51.211

192.168.51.211:3260,257 iqn.1998-01.com.vmware.52ecb04fd04ccfd2-0385259a575100b2

[root@db11 ~]# iscsiadm -m node -T iqn.1998-01.com.vmware.52ecb04fd04ccfd2-0385259a575100b2 -p 192.168.51.211 --login

Logging in to [iface: default, target: iqn.1998-01.com.vmware.52ecb04fd04ccfd2-0385259a575100b2, portal: 192.168.51.211,3260] (multiple)

Login to [iface: default, target: iqn.1998-01.com.vmware.52ecb04fd04ccfd2-0385259a575100b2, portal: 192.168.51.211,3260] successful.

 

vSAN による iSCSI の LUN がみえるようになります。

[root@db11 ~]# lsscsi

[2:0:0:0]    disk    VMware   Virtual disk     2.0   /dev/sda

[2:0:1:0]    disk    VMware   Virtual disk     2.0   /dev/sdb

[3:0:0:0]    cd/dvd  NECVMWar VMware SATA CD00 1.00  /dev/sr0

[33:0:0:0]   disk    VMware   Virtual SAN      0001  /dev/sdc

[33:0:0:1]   disk    VMware   Virtual SAN      0001  /dev/sdd

[33:0:0:2]   disk    VMware   Virtual SAN      0001  /dev/sde

 

接続先ターゲットが 1ホストだけではそのホストの障害にたえられないため、

のこりの 2台のホストにも接続してみます。

[root@db11 ~]# iscsiadm -m discovery -t sendtargets -p 192.168.51.212

192.168.51.212:3260,258 iqn.1998-01.com.vmware.52ecb04fd04ccfd2-0385259a575100b2

[root@db11 ~]# iscsiadm -m discovery -t sendtargets -p 192.168.51.213

192.168.51.213:3260,258 iqn.1998-01.com.vmware.52ecb04fd04ccfd2-0385259a575100b2

[root@db11 ~]# iscsiadm -m node -T iqn.1998-01.com.vmware.52ecb04fd04ccfd2-0385259a575100b2 --login

Logging in to [iface: default, target: iqn.1998-01.com.vmware.52ecb04fd04ccfd2-0385259a575100b2, portal: 192.168.51.212,3260] (multiple)

Logging in to [iface: default, target: iqn.1998-01.com.vmware.52ecb04fd04ccfd2-0385259a575100b2, portal: 192.168.51.213,3260] (multiple)

Login to [iface: default, target: iqn.1998-01.com.vmware.52ecb04fd04ccfd2-0385259a575100b2, portal: 192.168.51.212,3260] successful.

Login to [iface: default, target: iqn.1998-01.com.vmware.52ecb04fd04ccfd2-0385259a575100b2, portal: 192.168.51.213,3260] successful.

 

この Target には LUN を3つ作成していて、3 経路で接続しているので

9 つのデバイス(/dev/sdc ~ /dev/sdc)として認識されました。

各行の末尾にある文字列を見ると、どのデバイスが同じ LUN なのか判別できます。

例では、実際の LUN は下記の 3つだけです。

  • 1VMware_VITDEVID3a37b75af079a90e5e1e0050568adec3
  • 1VMware_VITDEVID6737b75a3cc0733f381a0050568adec3
  • 1VMware_VITDEVID7d37b75afa00ba22f8ea0050568adec3

[root@db11 ~]# lsscsi -i

[2:0:0:0]    disk    VMware   Virtual disk     2.0   /dev/sda   -

[2:0:1:0]    disk    VMware   Virtual disk     2.0   /dev/sdb   -

[3:0:0:0]    cd/dvd  NECVMWar VMware SATA CD00 1.00  /dev/sr0   -

[33:0:0:0]   disk    VMware   Virtual SAN      0001  /dev/sdc   1VMware_VITDEVID3a37b75af079a90e5e1e0050568adec3

[33:0:0:1]   disk    VMware   Virtual SAN      0001  /dev/sde   1VMware_VITDEVID6737b75a3cc0733f381a0050568adec3

[33:0:0:2]   disk    VMware   Virtual SAN      0001  /dev/sdh   1VMware_VITDEVID7d37b75afa00ba22f8ea0050568adec3

[34:0:0:0]   disk    VMware   Virtual SAN      0001  /dev/sdd   1VMware_VITDEVID3a37b75af079a90e5e1e0050568adec3

[34:0:0:1]   disk    VMware   Virtual SAN      0001  /dev/sdg   1VMware_VITDEVID6737b75a3cc0733f381a0050568adec3

[34:0:0:2]   disk    VMware   Virtual SAN      0001  /dev/sdi   1VMware_VITDEVID7d37b75afa00ba22f8ea0050568adec3

[35:0:0:0]   disk    VMware   Virtual SAN      0001  /dev/sdf   1VMware_VITDEVID3a37b75af079a90e5e1e0050568adec3

[35:0:0:1]   disk    VMware   Virtual SAN      0001  /dev/sdj   1VMware_VITDEVID6737b75a3cc0733f381a0050568adec3

[35:0:0:2]   disk    VMware   Virtual SAN      0001  /dev/sdk   1VMware_VITDEVID7d37b75afa00ba22f8ea0050568adec3

 

マルチパス デバイスの構成。(DM Multipath)

複数経路で LUN にアクセスしている iSCSI Initiator で /dev/sdX というデバイスのまま利用していると、

いずれかのパスで障害があったときに経路を切り替えることができません。

そこで、Linux での一般的な方法でマルチパス デバイスを構成してみます。

 

ここでは、Device Mapper Multipath(DM Multipath) を利用します。

device-mapper-multipath をインストールします。

[root@db11 ~]# yum install -y -q device-mapper-multipath

[root@db11 ~]# rpm -q device-mapper-multipath

device-mapper-multipath-0.4.9-111.el7_4.2.x86_64

 

そして構成&有効化します。

[root@db11 ~]# mpathconf --enable --with_multipathd y

[root@db11 ~]# systemctl is-active multipathd

active

[root@db11 ~]# mpathconf

multipath is enabled

find_multipaths is enabled

user_friendly_names is enabled

dm_multipath module is loaded

multipathd is running

 

マルチパスデバイス(/dev/mapper/mpatha ~ /dev/mapper/mpathc)が構成されました。

下記のように Virtual SAN(vSAN)の LUN による /dev/sdb ~ /dev/sdk が束ねられている様子が分かります。

[root@db11 ~]# multipath -ll

mpathc (1VMware_VITDEVID7d37b75afa00ba22f8ea0050568adec3) dm-5 VMware  ,Virtual SAN

size=30G features='0' hwhandler='0' wp=rw

|-+- policy='service-time 0' prio=1 status=active

| `- 33:0:0:2 sde 8:64  active ready running

|-+- policy='service-time 0' prio=1 status=enabled

| `- 34:0:0:2 sdi 8:128 active ready running

`-+- policy='service-time 0' prio=1 status=enabled

  `- 35:0:0:2 sdk 8:160 active ready running

mpathb (1VMware_VITDEVID6737b75a3cc0733f381a0050568adec3) dm-4 VMware  ,Virtual SAN

size=30G features='0' hwhandler='0' wp=rw

|-+- policy='service-time 0' prio=1 status=active

| `- 33:0:0:1 sdd 8:48  active ready running

|-+- policy='service-time 0' prio=1 status=enabled

| `- 34:0:0:1 sdg 8:96  active ready running

`-+- policy='service-time 0' prio=1 status=enabled

  `- 35:0:0:1 sdj 8:144 active ready running

mpatha (1VMware_VITDEVID3a37b75af079a90e5e1e0050568adec3) dm-3 VMware  ,Virtual SAN

size=30G features='0' hwhandler='0' wp=rw

|-+- policy='service-time 0' prio=1 status=active

| `- 33:0:0:0 sdc 8:32  active ready running

|-+- policy='service-time 0' prio=1 status=enabled

| `- 34:0:0:0 sdf 8:80  active ready running

`-+- policy='service-time 0' prio=1 status=enabled

  `- 35:0:0:0 sdh 8:112 active ready running

[root@db11 ~]#

 

iSCSI Target への接続。(Linux#2)

同様に、もう1台の Linux OS から iSCSI Target に接続します。

[root@db12 ~]# iscsiadm -m discovery -t sendtargets -p 192.168.51.211

192.168.51.211:3260,257 iqn.1998-01.com.vmware.52ecb04fd04ccfd2-0385259a575100b2

[root@db12 ~]# iscsiadm -m discovery -t sendtargets -p 192.168.51.212

192.168.51.212:3260,258 iqn.1998-01.com.vmware.52ecb04fd04ccfd2-0385259a575100b2

[root@db12 ~]# iscsiadm -m discovery -t sendtargets -p 192.168.51.213

192.168.51.213:3260,258 iqn.1998-01.com.vmware.52ecb04fd04ccfd2-0385259a575100b2

[root@db12 ~]# iscsiadm -m node -T iqn.1998-01.com.vmware.52ecb04fd04ccfd2-0385259a575100b2 --login

Logging in to [iface: default, target: iqn.1998-01.com.vmware.52ecb04fd04ccfd2-0385259a575100b2, portal: 192.168.51.211,3260] (multiple)

Logging in to [iface: default, target: iqn.1998-01.com.vmware.52ecb04fd04ccfd2-0385259a575100b2, portal: 192.168.51.212,3260] (multiple)

Logging in to [iface: default, target: iqn.1998-01.com.vmware.52ecb04fd04ccfd2-0385259a575100b2, portal: 192.168.51.213,3260] (multiple)

Login to [iface: default, target: iqn.1998-01.com.vmware.52ecb04fd04ccfd2-0385259a575100b2, portal: 192.168.51.211,3260] successful.

Login to [iface: default, target: iqn.1998-01.com.vmware.52ecb04fd04ccfd2-0385259a575100b2, portal: 192.168.51.212,3260] successful.

Login to [iface: default, target: iqn.1998-01.com.vmware.52ecb04fd04ccfd2-0385259a575100b2, portal: 192.168.51.213,3260] successful.

[root@db12 ~]# mpathconf --enable --with_multipathd y

[root@db12 ~]#

 

iSCSI Target に接続すると、1台目とはそれぞれの LUN のデバイス名(/dev/sdb~/dev/sdk)が異なっていることが分かります。

[root@db12 ~]# multipath -ll

mpathc (1VMware_VITDEVID7d37b75afa00ba22f8ea0050568adec3) dm-5 VMware  ,Virtual SAN

size=30G features='0' hwhandler='0' wp=rw

|-+- policy='service-time 0' prio=1 status=active

| `- 33:0:0:2 sdi 8:128 active ready running

|-+- policy='service-time 0' prio=1 status=enabled

| `- 34:0:0:2 sdj 8:144 active ready running

`-+- policy='service-time 0' prio=1 status=enabled

  `- 35:0:0:2 sdk 8:160 active ready running

mpathb (1VMware_VITDEVID6737b75a3cc0733f381a0050568adec3) dm-4 VMware  ,Virtual SAN

size=30G features='0' hwhandler='0' wp=rw

|-+- policy='service-time 0' prio=1 status=active

| `- 33:0:0:1 sdf 8:80  active ready running

|-+- policy='service-time 0' prio=1 status=enabled

| `- 34:0:0:1 sdg 8:96  active ready running

`-+- policy='service-time 0' prio=1 status=enabled

  `- 35:0:0:1 sdh 8:112 active ready running

mpatha (1VMware_VITDEVID3a37b75af079a90e5e1e0050568adec3) dm-3 VMware  ,Virtual SAN

size=30G features='0' hwhandler='0' wp=rw

|-+- policy='service-time 0' prio=1 status=active

| `- 33:0:0:0 sdc 8:32  active ready running

|-+- policy='service-time 0' prio=1 status=enabled

| `- 34:0:0:0 sdd 8:48  active ready running

`-+- policy='service-time 0' prio=1 status=enabled

  `- 35:0:0:0 sde 8:64  active ready running

[root@db12 ~]#

 

LUN のデバイス名ずれの様子について。

/dev/sdX という名前は、接続した Linux OS ごとに異なる状態になります。

しかもそのままでは永続化されない(OS 再起動などで名前が変わる)ものです。

LUN の番号ごとに、接続パスをもとにした /dev/disk/by-path 配下のデバイス名を見てみます。

Target のアドレスと sdX のデバイス名をめやすに見ると、

ノードごとに認識している名前がずれていることが判別しやすいと思います。

 

まず Linux OS #1 での LUN とデバイス名の対応です。

[root@db11 ~]# ls -l /dev/disk/by-path/ip-* | grep lun-0

lrwxrwxrwx. 1 root root 9  3月 25 16:04 /dev/disk/by-path/ip-192.168.51.211:3260-iscsi-iqn.1998-01.com.vmware.52ecb04fd04ccfd2-0385259a575100b2-lun-0 -> ../../sdc

lrwxrwxrwx. 1 root root 9  3月 25 16:04 /dev/disk/by-path/ip-192.168.51.212:3260-iscsi-iqn.1998-01.com.vmware.52ecb04fd04ccfd2-0385259a575100b2-lun-0 -> ../../sdf

lrwxrwxrwx. 1 root root 9  3月 25 16:04 /dev/disk/by-path/ip-192.168.51.213:3260-iscsi-iqn.1998-01.com.vmware.52ecb04fd04ccfd2-0385259a575100b2-lun-0 -> ../../sdh

[root@db11 ~]# ls -l /dev/disk/by-path/ip-* | grep lun-1

lrwxrwxrwx. 1 root root 9  3月 25 16:04 /dev/disk/by-path/ip-192.168.51.211:3260-iscsi-iqn.1998-01.com.vmware.52ecb04fd04ccfd2-0385259a575100b2-lun-1 -> ../../sdd

lrwxrwxrwx. 1 root root 9  3月 25 16:04 /dev/disk/by-path/ip-192.168.51.212:3260-iscsi-iqn.1998-01.com.vmware.52ecb04fd04ccfd2-0385259a575100b2-lun-1 -> ../../sdg

lrwxrwxrwx. 1 root root 9  3月 25 16:04 /dev/disk/by-path/ip-192.168.51.213:3260-iscsi-iqn.1998-01.com.vmware.52ecb04fd04ccfd2-0385259a575100b2-lun-1 -> ../../sdj

[root@db11 ~]# ls -l /dev/disk/by-path/ip-* | grep lun-2

lrwxrwxrwx. 1 root root 9  3月 25 16:04 /dev/disk/by-path/ip-192.168.51.211:3260-iscsi-iqn.1998-01.com.vmware.52ecb04fd04ccfd2-0385259a575100b2-lun-2 -> ../../sde

lrwxrwxrwx. 1 root root 9  3月 25 16:04 /dev/disk/by-path/ip-192.168.51.212:3260-iscsi-iqn.1998-01.com.vmware.52ecb04fd04ccfd2-0385259a575100b2-lun-2 -> ../../sdi

lrwxrwxrwx. 1 root root 9  3月 25 16:04 /dev/disk/by-path/ip-192.168.51.213:3260-iscsi-iqn.1998-01.com.vmware.52ecb04fd04ccfd2-0385259a575100b2-lun-2 -> ../../sdk

 

そして Linux OS #2 での LUN とデバイス名の対応です。

[root@db12 ~]# ls -l /dev/disk/by-path/ip-* | grep lun-0

lrwxrwxrwx. 1 root root 9  3月 25 16:16 /dev/disk/by-path/ip-192.168.51.211:3260-iscsi-iqn.1998-01.com.vmware.52ecb04fd04ccfd2-0385259a575100b2-lun-0 -> ../../sdc

lrwxrwxrwx. 1 root root 9  3月 25 16:16 /dev/disk/by-path/ip-192.168.51.212:3260-iscsi-iqn.1998-01.com.vmware.52ecb04fd04ccfd2-0385259a575100b2-lun-0 -> ../../sdd

lrwxrwxrwx. 1 root root 9  3月 25 16:16 /dev/disk/by-path/ip-192.168.51.213:3260-iscsi-iqn.1998-01.com.vmware.52ecb04fd04ccfd2-0385259a575100b2-lun-0 -> ../../sde

[root@db12 ~]# ls -l /dev/disk/by-path/ip-* | grep lun-1

lrwxrwxrwx. 1 root root 9  3月 25 16:16 /dev/disk/by-path/ip-192.168.51.211:3260-iscsi-iqn.1998-01.com.vmware.52ecb04fd04ccfd2-0385259a575100b2-lun-1 -> ../../sdf

lrwxrwxrwx. 1 root root 9  3月 25 16:16 /dev/disk/by-path/ip-192.168.51.212:3260-iscsi-iqn.1998-01.com.vmware.52ecb04fd04ccfd2-0385259a575100b2-lun-1 -> ../../sdg

lrwxrwxrwx. 1 root root 9  3月 25 16:16 /dev/disk/by-path/ip-192.168.51.213:3260-iscsi-iqn.1998-01.com.vmware.52ecb04fd04ccfd2-0385259a575100b2-lun-1 -> ../../sdh

[root@db12 ~]# ls -l /dev/disk/by-path/ip-* | grep lun-2

lrwxrwxrwx. 1 root root 9  3月 25 16:16 /dev/disk/by-path/ip-192.168.51.211:3260-iscsi-iqn.1998-01.com.vmware.52ecb04fd04ccfd2-0385259a575100b2-lun-2 -> ../../sdi

lrwxrwxrwx. 1 root root 9  3月 25 16:16 /dev/disk/by-path/ip-192.168.51.212:3260-iscsi-iqn.1998-01.com.vmware.52ecb04fd04ccfd2-0385259a575100b2-lun-2 -> ../../sdj

lrwxrwxrwx. 1 root root 9  3月 25 16:16 /dev/disk/by-path/ip-192.168.51.213:3260-iscsi-iqn.1998-01.com.vmware.52ecb04fd04ccfd2-0385259a575100b2-lun-2 -> ../../sdk

 

このような問題に対処するために、DM Multipath を利用します。

 

ほかにも、共有されたデバイスを識別しやすくするためにラベルを付与する仕組みがあったりします。

たとえば、Oracle RAC(で利用される自動ストレージ管理 / ASM)では ASMLib や ASM Filter Driver(ASMFD)

といったライブラリ / ドライバがあり、それらがラベルづけの機能も持ちます。

たとえば ASMFD では下記のようにラベルを付与でき、ノードをまたいでデバイス識別をしやすくします。

(イメージをお伝えするということで、いろいろ手順は省略しています。)

[root@db11 ~]# asmcmd afd_label DATA1 /dev/mapper/mpatha1 --init

[root@db11 ~]# asmcmd afd_label DATA2 /dev/mapper/mpathb1 --init

[root@db11 ~]# asmcmd afd_label DATA3 /dev/mapper/mpathc1 --init

[root@db11 ~]# asmcmd afd_lslbl '/dev/mapper/mpath*'

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

Label                     Duplicate  Path

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

DATA1                                 /dev/mapper/mpatha1

DATA2                                 /dev/mapper/mpathb1

DATA3                                 /dev/mapper/mpathc1

[root@db11 ~]#

 

vSAN の iSCSI Target を利用する場合は、耐障害性 / 可用性を考慮すると

接続先として複数の(ESXi ホストの) IP アドレスを指定することになるはずなのです。

実際に利用するとなると Initiator 側では、マルチパス構成やノードをまたいだデバイス共有に対応する工夫が必要になりそうです。

 

以上、Linux から vSAN の iSCSI Target に接続してみる話でした。

vSphere 環境では、ゲスト OS に VMware Tools をインストールすると

VM のレイヤから、ゲスト OS に付与されている IP アドレスを確認することができます。

PowerCLI> Get-VM db01 | Get-VMGuest | select VM,ToolsVersion,IPAddress | fl

 

VM           : db01

ToolsVersion : 10.1.5

IPAddress    : {192.168.11.171, 192.168.11.170, 192.168.11.173, 192.168.41.171...}

 

 

実は現在の vSphere の機能では、vNIC と IP アドレスの対応も確認できるようになっています。

この VM には vNIC が 2つあり、それぞれ vNIC に複数の IP アドレスが付与されている様子がわかります。

(ちなみにこの VM は Oracle RAC を構成している Linux ゲストで VIP を複数もっています。)

PowerCLI> Get-VM db01 | Get-VMGuest | select -ExpandProperty ExtensionData  | select -ExpandProperty Net

 

Network        : dvpg-vds01-vlan-1011

IpAddress      : {192.168.11.171, 192.168.11.170, 192.168.11.173}

MacAddress     : 00:50:56:8a:fc:d4

Connected      : True

DeviceConfigId : 4000

DnsConfig      :

IpConfig       : VMware.Vim.NetIpConfigInfo

NetBIOSConfig  :

 

Network        : dvpg-vds01-vlan-4001

IpAddress      : {192.168.41.171, 169.254.131.137}

MacAddress     : 00:50:56:8a:89:e3

Connected      : True

DeviceConfigId : 4001

DnsConfig      :

IpConfig       : VMware.Vim.NetIpConfigInfo

NetBIOSConfig  :

 

 

IPv6 のアドレスを付与されている場合も、下記のようにアドレスが認識されています。

(ちなみにこの VM は vSAN Witness Appliance で、本来は vNIC1 / vNIC2 は別セグメントの IP を付与します。)

PowerCLI> Get-VM hv-n43w | Get-VMGuest | select -ExpandProperty ExtensionData  | select -ExpandProperty Net

 

Network        : dvpg-vds01-vlan-0000

IpAddress      : {192.168.1.13, fe80::250:56ff:fe8a:180a, 2400:4030:8c62:5400:250:56ff:fe8a:180a}

MacAddress     : 00:50:56:8a:18:0a

Connected      : True

DeviceConfigId : 4000

DnsConfig      :

IpConfig       : VMware.Vim.NetIpConfigInfo

NetBIOSConfig  :

 

Network        : dvpg-vds01-nested

IpAddress      : {192.168.1.14, fe80::250:56ff:fe8a:79a0, 2400:4030:8c62:5400:250:56ff:fe8a:79a0}

MacAddress     : 00:50:56:8a:79:a0

Connected      : True

DeviceConfigId : 4001

DnsConfig      :

IpConfig       : VMware.Vim.NetIpConfigInfo

NetBIOSConfig  :

 

 

ためしに、下記のようなスクリプトを作成してみました。

get_guest_ip.ps1 · GitHub

 

実行すると、下記のように IP アドレスごとに情報を取得できます。

powercli-vnic-ip-01.png

 

PowerCLI スクリプトなどで工夫することで、

取得する情報を vNIC ごとから IP アドレスごとにしたり・・・・

PowerCLI> .\get_guest_ip.ps1 -VMs hv-n43w

 

VM           : hv-n43w

PowerState   : PoweredOn

ToolsState   : toolsOk

key          : 4000

Mac          : 00:50:56:8a:18:0a

Portgroup    : dvpg-vds01-vlan-0000

Connected    : True

IpAddress    : 192.168.1.13

PrefixLength : 24

 

VM           : hv-n43w

PowerState   : PoweredOn

ToolsState   : toolsOk

key          : 4000

Mac          : 00:50:56:8a:18:0a

Portgroup    : dvpg-vds01-vlan-0000

Connected    : True

IpAddress    : fe80::250:56ff:fe8a:180a

PrefixLength : 64

 

VM           : hv-n43w

PowerState   : PoweredOn

ToolsState   : toolsOk

key          : 4000

Mac          : 00:50:56:8a:18:0a

Portgroup    : dvpg-vds01-vlan-0000

Connected    : True

IpAddress    : 2400:4030:8c62:5400:250:56ff:fe8a:180a

PrefixLength : 64

 

VM           : hv-n43w

PowerState   : PoweredOn

ToolsState   : toolsOk

key          : 4001

Mac          : 00:50:56:8a:79:a0

Portgroup    : dvpg-vds01-nested

Connected    : True

IpAddress    : 192.168.1.14

PrefixLength : 24

 

VM           : hv-n43w

PowerState   : PoweredOn

ToolsState   : toolsOk

key          : 4001

Mac          : 00:50:56:8a:79:a0

Portgroup    : dvpg-vds01-nested

Connected    : True

IpAddress    : fe80::250:56ff:fe8a:79a0

PrefixLength : 64

 

VM           : hv-n43w

PowerState   : PoweredOn

ToolsState   : toolsOk

key          : 4001

Mac          : 00:50:56:8a:79:a0

Portgroup    : dvpg-vds01-nested

Connected    : True

IpAddress    : 2400:4030:8c62:5400:250:56ff:fe8a:79a0

PrefixLength : 64

 

 

IPv4 のアドレスだけを取得したりできるようになります。

PowerCLI> .\get_guest_ip.ps1 -VMs hv-n43w -IPv4Only

 

VM           : hv-n43w

PowerState   : PoweredOn

ToolsState   : toolsOk

key          : 4000

Mac          : 00:50:56:8a:18:0a

Portgroup    : dvpg-vds01-vlan-0000

Connected    : True

IpAddress    : 192.168.1.13

PrefixLength : 24

 

VM           : hv-n43w

PowerState   : PoweredOn

ToolsState   : toolsOk

key          : 4001

Mac          : 00:50:56:8a:79:a0

Portgroup    : dvpg-vds01-nested

Connected    : True

IpAddress    : 192.168.1.14

PrefixLength : 24

 

 

IP アドレスごとにすることで、

下記のように IP アドレス特定を工夫しやすくなるのではないかと思います。

PowerCLI> .\get_guest_ip.ps1 -VMs db01 -IPv4Only | where {$_.key -eq 4001} | where {$_.IpAddress -like "192.168.*"} | select IpAddress

 

IpAddress

---------

192.168.41.171

 

 

たとえば、VM のテンプレート展開で DHCP を使用している場合に

vNICの番号(4000~)や ポートグループ名(Network)をもとに IP アドレスを特定して、

後続処理の自動化で利用したりすることができると思います。

 

ちなみに今回は vSphere 6.5 U1 + PowerCLI 10.0 環境でためしています。

 

以上、PowerCLI で vNIC と IP アドレスの対応を確認してみる話でした。