Skip navigation
1 2 3 Previous Next

にほんごVMware

319 posts

ここからは、NSX の分散ファイアウォール(DFW)を PowerNSX で操作してみます。

 

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

HOL-1803-02-NET - VMware NSX - Distributed Firewall and Micro-Segmentation

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

 

今回は、いわゆる3層構成(Web / App / DB)アプリケーションを意識した

分散ファイアウォール ルールを、PowerNSX で作成してみます。

※HOL-1803-02-NET の、モジュール1のシナリオです。

※一番下のファイアウォール ルール「Default Rule」の Action は、あらかじめ Block にしておきます。

 

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

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

 

ファイアウォール セクションとセキュリティ グループの作成。

ファイアウォール セクションを作成して、そこにファイアウォール ルールを追加します。

 

ファイアウォール セクション「3-tier App」を作成します。

New-NsxFirewallSection -Name "3-tier App"

hol1803-powernsx-07-01.png

 

VM「web-01a」と「web-02a」が含まれるセキュリティ グループを作成します。

対象の VM は下記の 2台です。

$vms = Get-VM web-0[12]a.*

$vms

hol1803-powernsx-07-02.png

 

セキュリティグループ「Web-tier」を作成します。

あとでファイアウォールルールの指定で利用するため、ここで変数に入れておきます。

$web_sg = New-NsxSecurityGroup -Name Web-tier -IncludeMember $vms

$web_sg

hol1803-powernsx-07-03.png

 

外部 → Web 層のファイアウォール ルール作成。

Web 層の VM では、HTTPS と SSH サービスの通信を許可します。

特定のサービスを含めるとエラーになってしまうので、

今回は下記のような条件で 2つのサービスに絞っています。

$service_web = @()

$service_web += Get-NsxService -Name HTTPS | where {$_.isUniversal -eq "false"}

$service_web += Get-NsxService -Name SSH | where {$_.isUniversal -eq "false"}

$service_web

hol1803-powernsx-07-04.png

 

外部から Web 層へ通信を許可するルールを作成します。

Get-NsxFirewallSection -Name "3-tier App" | New-NsxFirewallRule -Name "Ext to Web" -Position Bottom -Destination $web_sg -Service $service_web -Action allow

hol1803-powernsx-07-05.png

 

Web 層 → App 層のファイアウォール ルール作成。

App 層のネットワークは「App_Tier_Logical_Switch」です。

$app_nw = Get-NsxLogicalSwitch -Name App_Tier_Logical_Switch

$app_nw

hol1803-powernsx-07-06.png

 

App サービスを定義しておきます。

$service_app = New-NsxService -Name MyApp -Protocol TCP -port 8443

$service_app

hol1803-powernsx-07-07.png

 

Web 層から App 層へ通信を許可するルールを作成します。

ファイアウォール セクションはルールを追加するたびにオブジェクトの再取得が必要なので

変数格納せずに、都度 Get-NsxFirewallSection で取得しています。

Get-NsxFirewallSection -Name "3-tier App" | New-NsxFirewallRule -Name "Web to App" -Position Bottom -Source $web_sg -Destination $app_nw -Service $service_app -Action allow

hol1803-powernsx-07-08.png

 

App 層 → DB 層のファイアウォール ルール作成。

DB 層のネットワークは「DB_Tier_Logical_Switch」です。

$db_nw = Get-NsxLogicalSwitch -Name DB_Tier_Logical_Switch

$db_nw

hol1803-powernsx-07-09.png

 

DB 層の VM では、このラボでは HTTP を許可します。

$service_db = Get-NsxService -Name HTTP | where {$_.isUniversal -eq "false"}

$service_db

hol1803-powernsx-07-10.png

 

App 層から DB 層へ通信を許可するルールを作成します。

Get-NsxFirewallSection -Name "3-tier App" | New-NsxFirewallRule -Name "App to Database" -Position Bottom -Source $app_nw -Destination $db_nw -Service $service_db -Action allow

hol1803-powernsx-07-11.png

 

これで「3-tier App」セクションには 3つのルールが作成されました。

Get-NsxFirewallSection -Name "3-tier App" | Get-NsxFirewallRule

hol1803-powernsx-07-12.png

 

vSphere Web Client からもルール追加されたことが確認できます。

hol1803-powernsx-07-13.png

 

さらに一番下のファイアウォール ルール「Default Rule」の Action を Block にすることで、

シナリオどおりデフォルト ルールで ping がブロックされつつ、

「Customer DB App」ページが表示できることが確認できるはずです。

 

ちなみに現行バージョンの NSX は基本機能でマルチテナント対応しているわけではないので、

実環境では、各ルールの「Applied To(適用先)」で環境やアプリケーションごとに

ルールの適用先を制御することになるかなと思います。

 

つづく!

今回は、ここまでのシナリオでの PowerNSX コマンドラインを工夫して

簡易的なスクリプトを作成してみます。

 

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

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

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

 

以前のシナリオで、NSX Edge Service Gateway(ESG)から

分散論理ルータ(DLR)への論理スイッチの付け替えをしました。

NSX の HoL シナリオを PowerNSX でためす。Part.2

 

このときの論理スイッチの付け替え作業を、スクリプトで簡略化してみます。

 

スクリプトの内容。

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

  • ESG のインターフェース名を指定して実行すると、
    論理スイッチとアドレス設定を DLR に移行します。
  • インターフェースは論理スイッチに接続されている必要があります。
    (標準 / 分散ポートグループではなく)
  • IP アドレス、サブネットマスク、ポートグループ(論理スイッチ)の設定は、
    ESG のインターフェースから情報取得することで、入力を省略しています。
  • 設定後の DLR のインターフェースの情報を表示します。

 

このスクリプトでは、例外処理(エラー処理など)は省略しています。

また、このラボの構成に合わせることで、スクリプトの内容を簡略化しています。

例えばトランスポートゾーンや NSX Edge の名前が決め打ちだったりしているので、

汎用的なスクリプトを作成する場合はさらに工夫が必要になります。

 

また、HoL のシナリオにある OSPF のルーティング設定はスクリプトに含まないので、

テストむけの「Customer DB App」ページを表示するには

OSPF を手作業で設定する必要があります。

 

スクリプトの内容は下記のようにしました。

migrate_hol_nw.ps1 · GitHub

# Usage:

#   PowerNSX> .\migrate_hol_nw.ps1 <ESG_IF_NAME>

 

$if_name = $args[0]

 

$tz = Get-NsxTransportZone -Name "RegionA0-Global-TZ"

$src_esg =  Get-NsxEdge -Name "Perimeter-Gateway-01"

$dst_dlr = Get-NsxLogicalRouter -Name "Distributed-Router-01"

 

# Disconnect from ESG

$if = $src_esg | Get-NsxEdgeInterface -Name $if_name

$if_ip = $if.addressGroups.addressGroup.primaryAddress

$if_prefix = $if.addressGroups.addressGroup.subnetPrefixLength

$if_pg_name = $if.portgroupName

$if | Clear-NsxEdgeInterface -Confirm:$false

 

$if_pg = Get-NsxLogicalSwitch -TransportZone $tz -Name $if_pg_name

 

# Disconnect to DLR

$dlr_if = $dst_dlr | New-NsxLogicalRouterInterface -Name $if_name -Type internal -ConnectedTo $if_pg -PrimaryAddress $if_ip -SubnetPrefixLength $if_prefix

$dst_dlr | Get-NsxLogicalRouterInterface -Name $if_name | % {

    $ip = $_.addressGroups.addressGroup

    $_ | select `

        Index,

        type,

        name,

        connectedToName,

        @{N="primaryAddress";E={$ip.primaryAddress}},

        @{N="Prefix";E={$ip.subnetPrefixLength}}

}

 

これは、下記のように HoL の環境に「テキストの送信」して使用します。

スクリプトの内容は、PowerShell のヒアドキュメント(「@'」と、「'@」で囲む)を利用して保存しています。

hol1803-powernsx-06-01.png

 

スクリプトでのインターフェース移行。

それでは、スクリプトを実行してみます。

まず、HoL シナリオでは移行しなかった Web_Tier インターフェースを移行してみます。

このインターフェースを移行すると後続のモジュールのシナリオに影響がありますが、

今回はこのモジュールだけ実行する想定として、移行してしまいます。

 

まず、vSphere Web Client からスクリプト実行前の状態を確認しておきます。

ESG の index 2 インターフェースに「Web_Tier」が設定されています。

hol1803-powernsx-06-02.png

 

インターフェース名「Web_Tier」を指定して、スクリプトを実行します。

インターフェースが移行されて、移行後の DLR インターフェース設定が表示されました。

PS> .\migrate_hol_nw.ps1 Web_Tier

hol1803-powernsx-06-03.png

 

移行元である ESG の index 2 のインターフェース はクリアされました。

hol1803-powernsx-06-04.png

 

そして、DLR には期待通り Web_Tier のインターフェースが作成されました。

hol1803-powernsx-06-05.png

 

さらに、App_Tier、DB‗Tier のインターフェースも移行してみます。

PS> .\migrate_hol_nw.ps1 App_Tier

PS> .\migrate_hol_nw.ps1 DB_Tier

hol1803-powernsx-06-06.png

 

ESG の App_Tier、DB_Tier が接続されていたインターフェースがクリアされました。

hol1803-powernsx-06-07.png

 

そして DLR にインターフェースが作成されました。

hol1803-powernsx-06-08.png

 

NSX の GUI 操作は画面遷移が多く、設定変更箇所が多くなる傾向があります。

手順のステップが多いけれども繰り返し実行されるようなものは、

このようにスクリプト等を利用した自動化により、作業の効率化や作業ミスの防止が見込めます。

 

まだつづく・・・

今回は、PowerNSX で NSX Edge Service Gateway(ESG)によるロードバランサを構成します。

 

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

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

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

 

ESG のデプロイ。

ロードバランサとして利用するため、新しい ESG をデプロイします。

 

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

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

 

ロードバランサで利用する場合も、デプロイされる ESG は同じ仮想アプライアンスです。

デプロイされるものは変わりませんが、

ここでは以前の投稿とは少しコマンドラインを変更してデプロイします。

NSX の HoL シナリオを PowerNSX でためす。Part.3

 

今回も、クラスタでは DRS を有効にしてしまいます。

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

 

ESG の仮想アプライアンスの設定を用意します。

今回はパラメータを変数で事前定義してから NSX Edge の仮想アプライアンスをデプロイします。

$esg_name = "OneArm-LoadBalancer"

$password = "VMware1!VMware1!"

$esg_spec = "compact"

$cluster = Get-Cluster RegionA01-MGMT01

$ds = Get-Datastore RegionA01-ISCSI01-COMP01

$vm_folder = Get-Folder -Type VM -Name "Discovered virtual machine"

$esg_dgw = "172.16.10.1"

 

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

ワンアーム 構成のロードバランサなので、インターフェースは最小限の1つだけ作成します。

$vnic0_name = "WebNetwork"

$vnic0_nw = Get-NsxLogicalSwitch -Name Web_Tier_Logical_Switch

$vnic0_type = "internal"

$vnic0_ip = "172.16.10.10"

$vnic0_prefix = 24

$vnic0 = New-NsxEdgeInterfaceSpec -Index 0 -Name $vnic0_name -Type $vnic0_type -ConnectedTo $vnic0_nw -PrimaryAddress $vnic0_ip -SubnetPrefixLength $vnic0_prefix

 

ESG をデプロイします。

New-NsxEdge -Name $esg_name -Username admin -Password $password -Cluster $cluster -Datastore $ds -FormFactor $esg_spec -VMFolder $vm_folder -Interface $vnic0 -EnableSSH -FwEnabled -FwDefaultPolicyAllow

hol1803-powernsx-05-01.png

 

ESG にデフォルトゲートウェイを設定します。

Get-NsxEdge -Name $esg_name | Get-NsxEdgeRouting | Set-NsxEdgeRouting -DefaultGatewayVnic 0 -DefaultGatewayAddress $esg_dgw -Confirm:$false

hol1803-powernsx-05-02.png

 

ESG にデフォルトゲートウェイが設定されたことが確認できます。

Get-NsxEdge -Name $esg_name | Get-NsxEdgeRouting | select -ExpandProperty staticRouting | select -ExpandProperty defaultRoute

hol1803-powernsx-05-03.png

 

ロードバランサの構成。

 

ESG のロードバランサを有効化します。

Get-NsxEdge -Name $esg_name | Get-NsxLoadBalancer | Set-NsxLoadBalancer -Enabled

hol1803-powernsx-05-04.png

 

アプリケーション プロファイルを作成します。

Get-NsxEdge $esg_name | Get-NsxLoadBalancer | New-NsxLoadBalancerApplicationProfile -Name OneArmWeb-01 -Type HTTPS -SslPassthrough

hol1803-powernsx-05-05.png

 

デフォルトの HTTPS モニタの設定です。

Get-NsxEdge $esg_name | Get-NsxLoadBalancer | Get-NsxLoadBalancerMonitor -Name default_https_monitor | fl

hol1803-powernsx-05-06.png

 

PowerNSX ではモニタの設定変更が難しいため、今回は URL の異なる新しいモニタを作成します。

Get-NsxEdge $esg_name | Get-NsxLoadBalancer | New-NsxLoadBalancerMonitor -Name default_https_monitor-2 -Interval 5 -Timeout 15 -MaxRetries 3 -TypeHttps -Method GET -Url /cgi-bin/app.py

hol1803-powernsx-05-07.png

 

作成したモニタを指定して、ロードバランサ プールを作成します。

$monitor = Get-NsxEdge $esg_name | Get-NsxLoadBalancer | Get-NsxLoadBalancerMonitor -Name default_https_monitor-2

Get-NsxEdge $esg_name | Get-NsxLoadBalancer | New-NsxLoadBalancerPool -Name Web-Tier-Pool-01 -Monitor $monitor -Algorithm round-robin

hol1803-powernsx-05-08.png

 

プールにメンバ サーバ(web-01a、web-02a)を追加します。

 

web-01a を追加します。

Get-NsxEdge $esg_name | Get-NsxLoadBalancer | Get-NsxLoadBalancerPool -Name Web-Tier-Pool-01 | Add-NsxLoadBalancerPoolMember -Name web-01a -IpAddress 172.16.10.11 -Port 443 -MonitorPort 443

 

 

web-02a を追加します。

Get-NsxEdge $esg_name | Get-NsxLoadBalancer | Get-NsxLoadBalancerPool -Name Web-Tier-Pool-01 | Add-NsxLoadBalancerPoolMember -Name web-02a -IpAddress 172.16.10.12 -Port 443 -MonitorPort 443

hol1803-powernsx-05-09.png

 

メンバが追加されたことが分かります。

Get-NsxEdge $esg_name | Get-NsxLoadBalancer | Get-NsxLoadBalancerPool -Name Web-Tier-Pool-01 | Get-NsxLoadBalancerPoolMember | ft -AutoSize

hol1803-powernsx-05-10.png

 

仮想サーバを作成します。

PowerNSX では、Add-NsxLoadBalancerVip で仮想サーバを作成できます。

$profile = Get-NsxEdge $esg_name | Get-NsxLoadBalancer | Get-NsxLoadBalancerApplicationProfile -Name OneArmWeb-01

Get-NsxEdge $esg_name | Get-NsxLoadBalancer | Add-NsxLoadBalancerVip -ApplicationProfile $profile -Name Web-Tier-VIP-01 -IpAddress 172.16.10.10 -Protocol https -Port 443 -DefaultPool $pool

hol1803-powernsx-05-11.png

 

これでロードバランサが構成されて、ラボの「1-Arm LB Customer DB」ページや、

ESG でのステータス確認ができるはずです。

 

続く・・・

NSX の HoL シナリオを PowerNSX でためす。Part.6

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

 

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

今回の内容をためすためには、Part.2 ~ Part.3 の内容を実施しておく必要があります。

NSX の HoL シナリオを PowerNSX でためす。Part.1

NSX の HoL シナリオを PowerNSX でためす。Part.2

NSX の HoL シナリオを PowerNSX でためす。Part.3

 

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

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

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

 

これまでのシナリオでデプロイした NSX Edge Service Gateway(ESG)である

Perimeter-Gateway-02 を利用して、ECMP のルーティングを構成します。

 

追加した ESG のダイナミック ルーティングを設定する。

これまでのシナリオで ESG / DLR の OSPF を有効化していますが、

ESG 「Perimeter-Gateway-02」では OSPF が未設定なので、ここで設定します。

Get-NsxEdge -Name Perimeter-Gateway-02 | Get-NsxEdgeRouting | Set-NsxEdgeRouting -RouterId 192.168.100.4 -EnableOspf -Confirm:$false

hol1803-powernsx-04-01.png

 

OSPF の Area ID を指定します。

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

hol1803-powernsx-04-02.png

 

OSPF のインターフェース マッピングを追加します。

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

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

hol1803-powernsx-04-03.png

 

既存の ESG では BGP が有効化されていますが、

Perimeter-Gateway-02 では 未設定なので、ここで有効にします。

Get-NsxEdge -Name Perimeter-Gateway-02 | Get-NsxEdgeRouting | Set-NsxEdgeRouting -EnableBgp -LocalAS 65001 -Confirm:$false

hol1803-powernsx-04-04.png

 

BGP ネイバーを追加します。

Get-NsxEdge -Name Perimeter-Gateway-02 | Get-NsxEdgeRouting | New-NsxEdgeBgpNeighbour -IpAddress 192.168.100.1 -RemoteAS 65002 -Confirm:$false

hol1803-powernsx-04-05.png

 

BGP と OSPF のルート再配布を有効化します。

Get-NsxEdge -Name Perimeter-Gateway-02 | Get-NsxEdgeRouting | Set-NsxEdgeRouting -EnableOspfRouteRedistribution -EnableBgpRouteRedistribution -Confirm:$false

hol1803-powernsx-04-06.png

 

OSPF のルート再配布を設定します。

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

 

BGP のルート再配布を設定します。

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

hol1803-powernsx-04-07.png

 

ECMP を有効化する。

 

それでは、ESG と 分散論理ルータ(DLR)で ECMP を有効化します。

 

DLR「Distributed-Router-01」です。

Get-NsxLogicalRouter -Name Distributed-Router-01 | Get-NsxLogicalRouterRouting | Set-NsxLogicalRouterRouting -EnableEcmp -Confirm:$false

hol1803-powernsx-04-08.png

 

ESG「Perimeter-Gateway-01」です。

※今回は ファイアウォールの無効化を省略しています。

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

hol1803-powernsx-04-09.png

 

ESG「Perimeter-Gateway-01」です。

Get-NsxEdge -Name Perimeter-Gateway-02 | Get-NsxEdgeRouting | Set-NsxEdgeRouting -EnableEcmp -Confirm:$false

hol1803-powernsx-04-10.png

 

これで、ラボの ESG 、DLR で ECMP が構成されました。

シナリオにある、ルーティング情報やパスの切り替えが確認できるはずです。

 

まだ続く・・・

NSX の HoL シナリオを PowerNSX でためす。Part.5

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

 

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

NSX の HoL シナリオを PowerNSX でためす。Part.1

NSX の HoL シナリオを PowerNSX でためす。Part.2

 

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

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

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

 

前回の投稿はこちら。

NSX の HoL シナリオを PowerNSX でためす。Part.1

 

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

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

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

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 で情報取得してみる話でした。

つづくかもしれない。