Skip navigation
1 2 3 Previous Next

にほんごVMware

309 posts

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 アドレスの対応を確認してみる話でした。

今回は、PowerCLI で 2 Node vSAN を構成してみます。

2 Node vSAN のセットアップも、通常の vSAN と同様に vSphere Web Client を使用できますが

PowerCLI でもセットアップすることができます。

 

以前に PowerCLI での vSAN セットアップを

VMware Hands-on Labs(HoL)でためす方法を投稿しましたが・・・

PowerCLI で vSAN セットアップをためしてみる。

 

今回も同様に、下記の HoL のモジュール 7 にあるシナリオを PowerCLI で実施してみます。

 

HOL-1808-01-HCI - vSAN v6.6 - Getting Started

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

 

ESXi ホストの準備。

最初に、vCenter へ接続してクラスタを作成しておきます。

PowerCLI> Connect-VIServer vcsa-01a.corp.local

PowerCLI> Get-Datacenter RegionA01 | New-Cluster -Name 2-Node-Stretched-Cluster

 

esx-05a.corp.local と esx-06a.corp.local をクラスタに移動します。

PowerCLI> Get-VMHost esx-05a.corp.local,esx-06a.corp.local | Move-VMHost -Location 2-Node-Stretched-Cluster

 

クラスタに移動されたすべてのホストのメンテナンスモードを解除します。

PowerCLI> Get-Cluster 2-Node-Stretched-Cluster | Get-VMHost | Set-VMHost -State Connected

 

VMkernel ポートで、vSAN の準備ができていることを確認します。

VMkernel ポート「vmk3」ではすでに vSAN のトラフィックが有効化されています。

(vSAN Witness ホストの VMkernel ポートの設定は、後であらためて確認します。)

PowerCLI> Get-Cluster 2-Node-Stretched-Cluster | Get-VMHost | Get-VMHostNetworkAdapter -VMKernel | select VMHost,Name,IP,VsanTrafficEnabled | sort VMHost,Name

 

このラボではすでに vSAN トラフィックが有効化されていますが、

有効化する場合は下記のようなコマンドラインになります。

PowerCLI> Get-Cluster 2-Node-Stretched-Cluster | Get-VMHost | Get-VMHostNetworkAdapter -Name vmk3 | Set-VMHostNetworkAdapter -VsanTrafficEnabled:$true -Confirm:$false

 

ESXi ホストのディスク構成を確認しておきます。

ここで、このラボでは各ホストで構成が若干違う(vmhba1:~ と vmhba2:~)ことがわかります。

PowerCLI> Get-Cluster 2-Node-Stretched-Cluster | Get-VMHost | Get-VMHostDisk | select VMHost,ScsiLun,TotalSectors | sort VMHost,ScsiLun

vsan1808m7-01.png

 

先程とは別の方法で、VMkernel ポートの設定を確認しておきます。

まだ vSAN Witness が有効化されていないことがわかります。

ここでは、Get-EsxCli により、PowerCLI から esxcli を実行しています。

esxcli で実行可能な作業であれば、このように PowerCLI を介して実行することも可能です。

ここでは、コマンドラインが簡潔な Get-EsxCli -V1 を利用しています。

PowerCLI> Get-VMHost esx-0[568]a.* | Get-VMHostNetworkAdapter -VMKernel | % {$vmk = $_.Name; $_ | select VMHost,Name,@{N="Tags";E={((($_.VMHost | Get-EsxCli).network.ip.interface.tag.get($vmk)).Tags | sort) -join ","}}} | sort VMHost,Name

vsan1808m7-02.png

 

ESXi ホスト「esx-05a.corp.local」の vmk0 に、未設定だった witness タグを付与してみます。

まだ vSAN Witness が有効化されていないことがわかります。

今度は先ほどとはことなり、Get-EsxCli -V2 で esxcli を実行しています。

Get-EsxCli -V2 ではオプション指定の方法が少し複雑になりますが、

かわりにオプションを指定しやすく(必須ではないオプションを省略しやすく)なっています。

PowerCLI> $esxcli = Get-VMHost esx-05a.corp.local | Get-EsxCli -V2

PowerCLI> $a = $esxcli.vsan.network.ipv4.add.CreateArgs()

PowerCLI> $a.interfacename = "vmk0"

PowerCLI> $a.traffictype = "witness"

PowerCLI> $esxcli.vsan.network.ipv4.add.Invoke($a)

 

そのまま下記のコマンド実行すると、設定されたことが確認できます。

PowerCLI> $esxcli.vsan.network.list.Invoke() | select VmkNicName,TrafficType

vsan1808m7-03.png

 

同様に ESXi ホスト「esx-06a.corp.local」の vmk0 に、witness タグを付与します。

(PowerCLI のプロンプトは省略しています。)

$esxcli = Get-VMHost esx-06a.corp.local | Get-EsxCli -V2

$a = $esxcli.vsan.network.ipv4.add.CreateArgs()

$a.interfacename = "vmk0"

$a.traffictype = "witness"

$esxcli.vsan.network.ipv4.add.Invoke($a)

$esxcli.vsan.network.list.Invoke() | select VmkNicName,TrafficType

 

VMkernel ポートの Tag 設定は下記のようになりました。

こちらでは witness は「VSANWitness」と表示されています。

vsan1808m7-02a.png

 

vSAN クラスタのセットアップ。

それでは、2 Node vSAN のセットアップをしていきます。

vSAN Witness 仮想アプライアンス「esx-08a.corp.local」は、

このラボではすでにデプロイとネットワーク設定が実施されています。

 

クラスタで vSAN を有効化します。

PowerCLI> Get-Cluster 2-Node-Stretched-Cluster | Set-Cluster -VsanEnabled:$true -Confirm:$false

Fault Domain を 2 ノードそれぞれに作成します。

優先 Fault Domain は Preferred でセカンダリは Secondary としますが、

ここではまだその区別はありません。

PowerCLI> New-VsanFaultDomain -Name Preferred -VMHost esx-05a.corp.local

PowerCLI> New-VsanFaultDomain -Name Secondary -VMHost esx-06a.corp.local

 

ストレッチ クラスタを有効化します。

ここで Witness ホストと、優先 Fault Domain を指定します。

PowerCLI> Get-Cluster 2-Node-Stretched-Cluster | Set-VsanClusterConfiguration -StretchedClusterEnabled:$true -WitnessHost esx-08a.corp.local -WitnessHostCacheDisk mpx.vmhba1:C0:T2:L0 -WitnessHostCapacityDisk mpx.vmhba1:C0:T1:L0 -PreferredFaultDomain Preferred

 

つづけて、vSAN ディスク グループを作成します。

それぞれにホストに、2つずつ ディスクグループを作成します。

今回は各ホストでキャッシュ用 SSD のデバイス名が異なるので、ディスクグループごとにコマンドラインを実行します。

 

esx-05a.corp.local の ディスクグループ#1

PowerCLI> Get-VMHost esx-05a.corp.local | New-VsanDiskGroup -SsdCanonicalName mpx.vmhba1:C0:T0:L0 -DataDiskCanonicalName mpx.vmhba3:C0:T0:L0,mpx.vmhba3:C0:T1:L0

 

esx-06a.corp.local の ディスクグループ#1

PowerCLI> Get-VMHost esx-06a.corp.local | New-VsanDiskGroup -SsdCanonicalName mpx.vmhba2:C0:T0:L0 -DataDiskCanonicalName mpx.vmhba3:C0:T0:L0,mpx.vmhba3:C0:T1:L0

 

esx-05a.corp.local の ディスクグループ#2

PowerCLI> Get-VMHost esx-05a.corp.local | New-VsanDiskGroup -SsdCanonicalName mpx.vmhba1:C0:T1:L0 -DataDiskCanonicalName mpx.vmhba4:C0:T0:L0,mpx.vmhba4:C0:T1:L0

 

esx-06a.corp.local の ディスクグループ#2

PowerCLI> Get-VMHost esx-06a.corp.local | New-VsanDiskGroup -SsdCanonicalName mpx.vmhba2:C0:T1:L0 -DataDiskCanonicalName mpx.vmhba4:C0:T0:L0,mpx.vmhba4:C0:T1:L0

 

vSAN データストアの名前を確認します。デフォルトで「vsanDatastore」になります。

PowerCLI> Get-Cluster 2-Node-Stretched-Cluster | Get-Datastore | where {$_.Type -eq "vsan"}

 

vSAN データストアに VM を作成しておきます。

PowerCLI> New-VM -Name vm01 -Datastore vsanDatastore -StorageFormat Thin -ResourcePool esx-05a.corp.local

 

今回は省略しますが、あわせて必要に応じて「仮想マシン ストレージ ポリシー」によるローカルアフィニティや、

DRS ルールでのアフィニティ ルールを設定したりします。

 

セットアップした 2 Node vSAN の様子。

PowerCLI で構成したとおり、2 Node vSAN はストレッチ クラスタとなり、

Preferred と Secondary のうち、Preferred が優先 Fault Domain になっています。

vsan1808m7-04.png

 

vSAN Health でも「Storeched cluster」が緑になっています。

ハードウェア互換性に関連するエラーなどがありますが、HoL の仕様上ここでは無視します。

vsan1808m7-05.png

 

vSAN データストアに作成した VM「vm01」は、

データが格納される Component がそれぞれの Fault Domain(Preferred と Secondary)、

Witness が Witness ホストに配置されています。

(今回はデフォルトの仮想マシン ストレージ ポリシーのままです。)

vsan1808m7-06.png

 

vSphere Web Client で簡単に 2 Node vSAN を構成できますが、

PowerCLI を利用すると Fault Domain を手動作成したりするので

より理解を深められるのではないかと思います。

 

2 Node vSAN はリモートオフィス / ブランチオフィスへの配置をユースケースとしているようで

大量展開や省力化のためか自動化のサンプルが多くあります。

VMware Sample Exchange などにもサンプルが多いので、いろいろと挑戦してみたいところです。

vSAN Samples - Samples - VMware {code}

 

以上、PowerCLI で 2 Node vSAN を構成してみる話でした。

vSAN のセットアップには一般的 vSphere Web Client を使用しますが、PowerCLI でも同様の操作ができます。

PowerCLI での vSAN 設定を、 VMware Hands-on Labs(HoL)でためす方法を紹介します。

 

HoL には、vSAN 入門者むけの下記のラボがあります。

 

HOL-1808-01-HCI - vSAN v6.6 - Getting Started

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

 

このラボには PowerCLI を使用するシナリオがあるのですが、

モジュール 1 での vSAN クラスタのセットアップは vSphere Web Client で実施しています。

今回は、その部分を操作を PowerCLI に置き換えてみます。

 

ちなみにラボのシナリオ(マニュアル)は公開されており、下記で確認できます。

 

VMware Hands-on Labs - HOL-1808-01-HCI

http://docs.hol.vmware.com/HOL-2018/Localization/manuals/ja/manualexport-hol-1808-01-hci.zip_html_en/

 

コマンドラインの実行方法について。

コマンドラインは「テキストの送信」を利用すると、HoL に対してコピー&ペーストができるようになります。

(ただし、逆の HoL からのコピーはできません。)

デスクトップにある「VMware PowerCLI」のアイコンから PowerCLI のウインドウを起動しておき、

「送信」をクリックする前に、フォーカスをあてておきます。

vsan-powercli-hol-01.png

 

ちなみに HoL の PowerCLI で実施できる vSAN 関連の操作は、

下記のようなコマンドラインで俯瞰することができます。

PowerCLI> gcm -Module VMware.VimAutomation.Storage | group Noun | select Count,Name,@{N="Verb";E={$_.Group.Verb -join ","}} | sort Name

 

PowerCLI での vSAN クラスタのセットアップをためす。

それでは、vSAN のセットアップをしていきます。

 

まず、vCenter に接続します。

HoL では、パスワードなしでログインできるように構成されています。

PowerCLI> Connect-VIServer vcsa-01a.corp.local

 

今回は、クラスタのオブジェクトを取得して変数「$c」に格納おきます。

HoL へのコピー&ペーストの都合上、短い変数名にしました。

PowerCLI> $c = Get-Cluster RegionA01-COMP01

 

下記のようなコマンドラインで、クラスタの情報を確認できます。

PowerCLI> $c

PowerCLI> $c | select *

PowerCLI> $c | select Name,VsanEnabled

 

クラスタに含まれる ESXi ホストを確認しておきます。

PowerCLI> $c | Get-VMHost | sort Name

 

それでは、vSAN を有効化します。

「-Confirm:$false」でコマンド実行の確認メッセージを抑止しています。

どうしても確認しつつコマンドラインを実行したい場合は、はこのオプションは不要です。

PowerCLI> $c | Set-Cluster -VsanEnabled:$true -Confirm:$false

PowerCLI> $c | Get-VsanClusterConfiguration | Set-VsanClusterConfiguration -SpaceEfficiencyEnabled:$true -AllowReducedRedundancy:$true -Confirm:$false

 

クラスタの vSAN 設定を確認します。

SpaceEfficiencyEnabled では、重複排除と圧縮が有効になっているか確認できます。

設定時の AllowReducedRedundancy は、設定反映時に一時的な冗長性の低下を許容するというオプションなので

ここでのクラスタの設定確認には含めません。

PowerCLI> $c | Get-VsanClusterConfiguration | select Cluster,VsanEnabled,SpaceEfficiencyEnabled

 

VMkernel ポートで vSAN トラフィックが有効化されているか確認しておきます。

PowerCLI> $c | Get-VMHost | Get-VMHostNetworkAdapter -VMKernel -Name vmk3 | select VMHost,Name,IP,VsanTrafficEnabled,PortGroupName | sort VMHost,Name | ft -AutoSize

 

クラスタに含まれるすべてのホストに対して、vSAN のディスク グループを作成します。

ホストに搭載されたディスクは、下記のようなコマンドラインで確認できます。

PowerCLI>  $c | Get-VMHost | Get-VMHostDisk | select VMHost,ScsiLun,TotalSectors | sort VMHost,ScsiLun

 

すべてのホストでハードウェア構成が揃っているので、

SsdCanonicalName と DataDiskCanonicalName  のデバイス名もすべてのホストで揃えられます。

今回はシナリオにあわせて、キャッシュ層として mpx.vmhba1:C0:T1:L0、

キャパシティ層として mpx.vmhba3:C0:T1:L0 と mpx.vmhba4:C0:T1:L0 を追加します。

PowerCLI> $c | Get-VMHost | New-VsanDiskGroup -SsdCanonicalName mpx.vmhba1:C0:T1:L0 -DataDiskCanonicalName mpx.vmhba3:C0:T1:L0,mpx.vmhba4:C0:T1:L0

 

vSAN のディスク グループにディスクが追加されたことを確認します。

PowerCLI> $c | Get-VMHost | %{$hv_name =$_.Name; $_ | Get-VsanDisk | select @{N="VMHost";E={$hv_name}},CanonicalName,IsCacheDisk,VsanDiskGroup} | sort VMHost

 

vSAN データストアの容量は、下記で確認できます。

クラスタの vSAN 設定が更新されているため、以前に取得した $c ではなく

Get-Cluster でクラスタのオブジェクトを取得しなおす必要があります。

PowerCLI> Get-Cluster RegionA01-COMP01 | Get-VsanSpaceUsage | select *

 

これで、モジュール 1 の完了時点と同様の vSAN 環境ができました。

 

このモジュールのシナリオにはありませんが、のこりのディスクで

追加のディスクグループを作成することもできます。

ディスクグループでコントローラを分割したほうがよいとは思いますが、

今回は HoL シナリオの都合上、下記のようにディスクを選択しています。

PowerCLI> $c | Get-VMHost | New-VsanDiskGroup -SsdCanonicalName mpx.vmhba1:C0:T0:L0 -DataDiskCanonicalName mpx.vmhba3:C0:T0:L0,mpx.vmhba4:C0:T0:L0

 

このように、vSphere Web Client での vSAN 操作のほとんどは PowerCLI でも実施できます。

作業を PowerCLI に置き換えることで、設定の効率化やミスの防止などをはかれるかもしれません。

 

また、PowerCLI で vSAN 環境を確認する方法については下記の投稿もどうぞ。

vSAN の情報を PowerCLI 6.5 R1 で見てみる。

 

以上、HoL を利用して PowerCLI による vSAN セットアップをためしてみる話でした。

以前の投稿で PowerCLI を利用して、vSAN 環境の Oracle RAC VM の情報を確認する方法を紹介しました。

PowerCLI で vSphere / vSAN 環境での Oracle RAC むけ VM の構成情報を取得してみる。

 

今回は、その VM を PowerCLI で作成する方法を紹介します。

vCenter 6.5 U1 / ESXi 6.5 U1 の vSAN 環境で、

PowerCLI は、あえて Oracle Linux 7 で使用してみました。

Linux で PowerCLI 10.0 をためしてみる。

 

VM の作成 / クローン。

今回は、db00-template というテンプレートの VM を用意しています。

テンプレート VM には、Oracle Linux 7 がインストールして、

rpm パッケージのアップデートなども済ませておくとよいと思います。

 

テンプレート VM をクローンします。

最初は Get-VM にしていますが、VM を「テンプレート」に変換している場合は Get-Template になります。

DRS を有効化している環境では、ESXi ではなく クラスタ / リソースプールを指定してクローンできます。

  • 今回のクローン先とし指定している リソースプール「rp-lab」は作成ずみです。
  • 仮想マシン フォルダ「vsan-oracle-rac」も作成ずみです。
  • クローン先のデータストアは vSAN データストア「vsanDatastore-01」です。
  • テンプレート VM には OS 領域の VMDK しかないので、Thin プロビジョニングにしています。

PS /home/gowatana> Get-VM db00-template | New-VM -ResourcePool rp-lab -Datastore vsanDatastore-01 -StorageFormat Thin -Location vsan-oracle-rac -Name db01

PS /home/gowatana> Get-VM db00-template | New-VM -ResourcePool rp-lab -Datastore vsanDatastore-01 -StorageFormat Thin -Location vsan-oracle-rac -Name db02

 

作成された VM です。

下記で見られる VM のスペックは、テンプレートの VM から引き継がれています。

PS /home/gowatana> Get-VM db0? | select Name,PowerState,NumCpu,MemoryGB,Version,GuestId,VMHost | Sort-Object Name | ft -AutoSize

 

Name PowerState NumCpu MemoryGB Version GuestId              VMHost

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

db01 PoweredOff      2        8     v13 oracleLinux7_64Guest hv-i21.go-lab.jp

db02 PoweredOff      2        8     v13 oracleLinux7_64Guest hv-i21.go-lab.jp

 

 

vNIC の追加。

分散ポートグループの作成と、vNIC を追加します。

  • 今回の RAC では、Public(テンプレート VM にすでに作成ずみの vNIC#1)と Private(追加する vNIC#2)の NIC を使用する想定とします。
  • ASM 用のネットワークを分離できますが、今回は Private と兼用にします。
  • 共有ディスクは VMDK ファイルの共有で用意するので、NFS / iSCSI ネットワークも用意しません。
  • Private ネットワークむけに VLAN をわけたポートグループ作成して、vNIC はそこに接続します。
    ちなみに、この環境では分散仮想スイッチ(vDS)を利用しています。

 

まだ、それぞれの VM に vNIC は 1つだけです。

PS /home/gowatana> Get-VM db0? | Get-NetworkAdapter | select Parent,Name,Type,NetworkName,@{N="StartConnected";E={$_.ConnectionState.StartConnected}},@{N="Connected";E={$_.ConnectionState.Connected}} | Sort-Object Parent,Name | ft -AutoSize

 

Parent Name                 Type NetworkName          StartConnected Connected

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

db01   Network adapter 1 Vmxnet3 dvpg-vds01-vlan-1011           True     False

db02   Network adapter 1 Vmxnet3 dvpg-vds01-vlan-1011           True     False

 

 

分散ポートグループを作成します。

PS /home/gowatana> Get-VDSwitch vds01 | New-VDPortgroup -Name dvpg-vds01-vlan-4001 -VlanId 4001

 

vNIC#2 を追加します。

PS /home/gowatana> Get-VM db0? | New-NetworkAdapter -Type Vmxnet3 -Portgroup dvpg-vds01-vlan-4001 -StartConnected:$true 

 

vNIC#2 が追加されました。

PS /home/gowatana> Get-VM db0? | Get-NetworkAdapter | select Parent,Name,Type,NetworkName,@{N="StartConnected";E={$_.ConnectionState.StartConnected}},@{N="Connected";E={$_.ConnectionState.Connected}} | Sort-Object Parent,Name | ft -AutoSize

 

Parent Name                 Type NetworkName          StartConnected Connected

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

db01   Network adapter 1 Vmxnet3 dvpg-vds01-vlan-1011           True     False

db01   Network adapter 2 Vmxnet3 dvpg-vds01-vlan-4001           True     False

db02   Network adapter 1 Vmxnet3 dvpg-vds01-vlan-1011           True     False

db02   Network adapter 2 Vmxnet3 dvpg-vds01-vlan-4001           True     False

 

 

VMDK の追加。(ローカル ディスクむけ)

VM に、ローカル ディスク むけの VMDK を追加します。

これは、ソフトウェアをインストールする領域として利用します。

(いわゆる ORACLE_BASE / ORACLE_HOME / GRID_HOME...)

このディスクは、特にファイルシステムを分ける必要がない場合は不要ですが、

一般的にはファイルシステムを分割するのではないかと思います。

 

VM テンプレートでは VMDK#1 だけの状態でした。

PS /home/gowatana> Get-VM db0? | Get-HardDisk | select Parent,Name,CapacityGB,Filename | Sort-Object Parent,Name

 

Parent Name        CapacityGB Filename

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

db01   Hard disk 1         16 [vsanDatastore-01] 60c4ab5a-6c3e-ca85-29da-b8aeedea7a23/db01.vmdk

db02   Hard disk 1         16 [vsanDatastore-01] cac6ab5a-1074-611f-a546-b8aeedea7a23/db02.vmdk

 

 

VMDK を追加します。

PS /home/gowatana> Get-VM db0? | New-HardDisk -Datastore vsanDatastore-01 -CapacityGB 40 -StorageFormat Thin

 

VMDK が追加されました。

PS /home/gowatana> Get-VM db0? | Get-HardDisk | select Parent,Name,CapacityGB,Filename | Sort-Object Parent,Name

 

Parent Name        CapacityGB Filename

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

db01   Hard disk 1         16 [vsanDatastore-01] 60c4ab5a-6c3e-ca85-29da-b8aeedea7a23/db01.vmdk

db01   Hard disk 2         40 [vsanDatastore-01] 60c4ab5a-6c3e-ca85-29da-b8aeedea7a23/db01_1.vmdk

db02   Hard disk 1         16 [vsanDatastore-01] cac6ab5a-1074-611f-a546-b8aeedea7a23/db02.vmdk

db02   Hard disk 2         40 [vsanDatastore-01] cac6ab5a-1074-611f-a546-b8aeedea7a23/db02_1.vmdk

 

 

VMDK の追加。(共有ディスクむけ / db01 側)

RAC の共有ディスクとして利用するための VMDK を追加します。

共有ディスクとして利用する VMDK ファイルの作成は、1台の VM(今回は db01)で実施します。

  • 共有ディスクむけの VMDK は、仮想 SCSI コントローラ(vSCSI Controller)を分けておきます。
  • EagerZeroed Thick にしておきます。
  • スナップショットの対象外になるように「-Persistence IndependentPersistent」にしておきます。

 

デフォルトでは、vSCSI Controller は 1つだけのはずです。

PS /home/gowatana> Get-VM db0? | Get-ScsiController | select Parent,Name,Type,BusSharingMode | Sort-Object Parent

 

Parent Name                     Type BusSharingMode

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

db01   SCSI controller 0 ParaVirtual      NoSharing

db02   SCSI controller 0 ParaVirtual      NoSharing

 

 

VMDK と vSCSI Controller を追加します。

PS /home/gowatana> Get-VM db01 | New-HardDisk -CapacityGB 30 -Datastore vsanDatastore-01 -StorageFormat EagerZeroedThick -Persistence IndependentPersistent | New-ScsiController -Type ParaVirtual

 

これで、vSCSI Controllr と VMDK が同時に追加されます。

PS /home/gowatana> Get-VM db01 | Get-ScsiController | select Parent,Name,Type,BusSharingMode

 

Parent Name                     Type BusSharingMode

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

db01   SCSI controller 0 ParaVirtual      NoSharing

db01   SCSI controller 1 ParaVirtual      NoSharing

 

 

PS /home/gowatana> Get-VM db01 | Get-HardDisk | Get-SpbmEntityConfiguration | ft -AutoSize

 

Entity      Storage Policy    Status    Time Of Check

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

Hard disk 1 vsan-policy-raid5 compliant 2018/03/16 18:45:07

Hard disk 2 vsan-policy-raid5 compliant 2018/03/16 21:21:45

Hard disk 3                   none

 

 

さらに VMDK を追加する場合は、ここで追加された 「SCSI controller 1」を指定します。

今回は、あと 5つ追加します。

PS /home/gowatana> Get-VM db01 | New-HardDisk -CapacityGB 30 -Datastore vsanDatastore-01 -StorageFormat EagerZeroedThick -Persistence IndependentPersistent -Controller "SCSI controller 1"

PS /home/gowatana> Get-VM db01 | New-HardDisk -CapacityGB 30 -Datastore vsanDatastore-01 -StorageFormat EagerZeroedThick -Persistence IndependentPersistent -Controller "SCSI controller 1"

PS /home/gowatana> Get-VM db01 | New-HardDisk -CapacityGB 30 -Datastore vsanDatastore-01 -StorageFormat EagerZeroedThick -Persistence IndependentPersistent -Controller "SCSI controller 1"

PS /home/gowatana> Get-VM db01 | New-HardDisk -CapacityGB 30 -Datastore vsanDatastore-01 -StorageFormat EagerZeroedThick -Persistence IndependentPersistent -Controller "SCSI controller 1"

PS /home/gowatana> Get-VM db01 | New-HardDisk -CapacityGB 30 -Datastore vsanDatastore-01 -StorageFormat EagerZeroedThick -Persistence IndependentPersistent -Controller "SCSI controller 1"

 

結果的に、Controller 1001 の VMDK#3~#8 が追加されました。

PS /home/gowatana> Get-VM db01 | Get-HardDisk | select Parent,Name,CapacityGB,@{N="Controller";E={$_.ExtensionData.ControllerKey}},StorageFormat,@{N="StoragePolicy";E={($_|Get-SpbmEntityConfiguration).StoragePolicy}} | Sort-Object Parent,Name | ft -AutoSize

 

Parent Name        CapacityGB Controller    StorageFormat StoragePolicy

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

db01   Hard disk 1         16       1000             Thin vsan-policy-raid5

db01   Hard disk 2         40       1000             Thin vsan-policy-raid5

db01   Hard disk 3         30       1001 EagerZeroedThick

db01   Hard disk 4         30       1001 EagerZeroedThick vsan-policy-raid5

db01   Hard disk 5         30       1001 EagerZeroedThick vsan-policy-raid5

db01   Hard disk 6         30       1001 EagerZeroedThick vsan-policy-raid5

db01   Hard disk 7         30       1001 EagerZeroedThick vsan-policy-raid5

db01   Hard disk 8         30       1001 EagerZeroedThick vsan-policy-raid5

 

 

VMDK ファイルは、すべて vSAN データストアに格納されています。

PS /home/gowatana> Get-VM db01 | Get-HardDisk | select Parent,Name,Filename | Sort-Object Parent,Name | ft -AutoSize

 

Parent Name        Filename

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

db01   Hard disk 1 [vsanDatastore-01] 60c4ab5a-6c3e-ca85-29da-b8aeedea7a23/db01.vmdk

db01   Hard disk 2 [vsanDatastore-01] 60c4ab5a-6c3e-ca85-29da-b8aeedea7a23/db01_1.vmdk

db01   Hard disk 3 [vsanDatastore-01] 60c4ab5a-6c3e-ca85-29da-b8aeedea7a23/db01_2.vmdk

db01   Hard disk 4 [vsanDatastore-01] 60c4ab5a-6c3e-ca85-29da-b8aeedea7a23/db01_3.vmdk

db01   Hard disk 5 [vsanDatastore-01] 60c4ab5a-6c3e-ca85-29da-b8aeedea7a23/db01_4.vmdk

db01   Hard disk 6 [vsanDatastore-01] 60c4ab5a-6c3e-ca85-29da-b8aeedea7a23/db01_5.vmdk

db01   Hard disk 7 [vsanDatastore-01] 60c4ab5a-6c3e-ca85-29da-b8aeedea7a23/db01_6.vmdk

db01   Hard disk 8 [vsanDatastore-01] 60c4ab5a-6c3e-ca85-29da-b8aeedea7a23/db01_7.vmdk

 

 

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

RAC の共有ディスクむけに、仮想マシン ストレージ ポリシーを作成します。

  • オブジェクト領域予約を 100% にします。
  • 許容される障害数(FTT)を 1 にします。
  • オブジェクトあたりのディスク ストライプ数は 2 にします。

PS /home/gowatana> $r1 = New-SpbmRule -Capability (Get-SpbmCapability -Name VSAN.proportionalCapacity) -Value 100

PS /home/gowatana> $r2 = New-SpbmRule -Capability (Get-SpbmCapability -Name VSAN.hostFailuresToTolerate) -Value 1

PS /home/gowatana> $r3 = New-SpbmRule -Capability (Get-SpbmCapability -Name VSAN.stripeWidth) -Value 2

PS /home/gowatana> $rs1 = New-SpbmRuleSet -AllOfRules $r1, $r2, $r3

PS /home/gowatana> New-SpbmStoragePolicy -Name vsan-policy-rac-01 -AnyOfRuleSets $rs1

 

ポリシーが作成されました。

PS /home/gowatana> Get-SpbmStoragePolicy -Name "vsan-policy-rac-01" | select -ExpandProperty AnyOfRuleSets | %{$name = $_.Name; $_ | select -ExpandProperty AllOfRules | select @{N="RuleName";E={$Name}},Capability,Value} | ft -AutoSize

 

RuleName   Capability                  Value

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

Rule-Set 1 VSAN.proportionalCapacity     100

Rule-Set 1 VSAN.hostFailuresToTolerate     1

Rule-Set 1 VSAN.stripeWidth                2

 

 

VMDK へのポリシー割り当て。(db01)

共有ディスクむけの VMDK にポリシーを割り当てます。

接続されている vSCSI Controller を識別したほうがよいと思いますが、

今回は Persistence を IndependentPersistent にしている VMDK に対して割り当てます。

(見分けやすいので)

PS /home/gowatana> Get-VM db01 | Get-HardDisk | where {$_.Persistence -eq "IndependentPersistent"} | Set-SpbmEntityConfiguration -StoragePolicy vsan-policy-rac-01

 

vSCSI Controller 1(Key が 1001)の VMDK のポリシーが変更されました。

PS /home/gowatana> Get-VM db01 | Get-HardDisk | select Parent,Name,CapacityGB,@{N="Controller";E={$_.ExtensionData.ControllerKey}},StorageFormat,@{N="StoragePolicy";E={($_|Get-SpbmEntityConfiguration).StoragePolicy}} | Sort-Object Parent,Name | ft -AutoSize

 

Parent Name        CapacityGB Controller    StorageFormat StoragePolicy

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

db01   Hard disk 1         16       1000             Thin vsan-policy-raid5

db01   Hard disk 2         40       1000             Thin vsan-policy-raid5

db01   Hard disk 3         30       1001 EagerZeroedThick vsan-policy-rac-01

db01   Hard disk 4         30       1001 EagerZeroedThick vsan-policy-rac-01

db01   Hard disk 5         30       1001 EagerZeroedThick vsan-policy-rac-01

db01   Hard disk 6         30       1001 EagerZeroedThick vsan-policy-rac-01

db01   Hard disk 7         30       1001 EagerZeroedThick vsan-policy-rac-01

db01   Hard disk 8         30       1001 EagerZeroedThick vsan-policy-rac-01

 

 

VMDK の追加。(共有ディスクむけ / db02 側)

db02 に、仮想ディスクを接続します。

db01 の下記のディスクが対象になります。

PS /home/gowatana> Get-VM db01 | Get-HardDisk | where {$_.Persistence -eq "IndependentPersistent"} | select Name,Filename

 

Name        Filename

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

Hard disk 3 [vsanDatastore-01] 60c4ab5a-6c3e-ca85-29da-b8aeedea7a23/db01_2.vmdk

Hard disk 4 [vsanDatastore-01] 60c4ab5a-6c3e-ca85-29da-b8aeedea7a23/db01_3.vmdk

Hard disk 5 [vsanDatastore-01] 60c4ab5a-6c3e-ca85-29da-b8aeedea7a23/db01_4.vmdk

Hard disk 6 [vsanDatastore-01] 60c4ab5a-6c3e-ca85-29da-b8aeedea7a23/db01_5.vmdk

Hard disk 7 [vsanDatastore-01] 60c4ab5a-6c3e-ca85-29da-b8aeedea7a23/db01_6.vmdk

Hard disk 8 [vsanDatastore-01] 60c4ab5a-6c3e-ca85-29da-b8aeedea7a23/db01_7.vmdk

 

 

db02 の最初の共有 VMDK を接続するときに、あわせて vSCSI Controller を追加します。

PS /home/gowatana> Get-VM db02 | New-HardDisk -DiskPath "[vsanDatastore-01] 60c4ab5a-6c3e-ca85-29da-b8aeedea7a23/db01_2.vmdk" -Persistence IndependentPersistent | New-ScsiController -Type ParaVirtual

 

Type                 BusSharingMode       UnitNumber

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

ParaVirtual          NoSharing                     4

 

 

残りの VMDK も接続します。

PS /home/gowatana> Get-VM db02 | New-HardDisk -DiskPath "[vsanDatastore-01] 60c4ab5a-6c3e-ca85-29da-b8aeedea7a23/db01_3.vmdk" -Persistence IndependentPersistent -Controller "SCSI controller 1"

PS /home/gowatana> Get-VM db02 | New-HardDisk -DiskPath "[vsanDatastore-01] 60c4ab5a-6c3e-ca85-29da-b8aeedea7a23/db01_4.vmdk" -Persistence IndependentPersistent -Controller "SCSI controller 1"

PS /home/gowatana> Get-VM db02 | New-HardDisk -DiskPath "[vsanDatastore-01] 60c4ab5a-6c3e-ca85-29da-b8aeedea7a23/db01_5.vmdk" -Persistence IndependentPersistent -Controller "SCSI controller 1"

PS /home/gowatana> Get-VM db02 | New-HardDisk -DiskPath "[vsanDatastore-01] 60c4ab5a-6c3e-ca85-29da-b8aeedea7a23/db01_6.vmdk" -Persistence IndependentPersistent -Controller "SCSI controller 1"

PS /home/gowatana> Get-VM db02 | New-HardDisk -DiskPath "[vsanDatastore-01] 60c4ab5a-6c3e-ca85-29da-b8aeedea7a23/db01_7.vmdk" -Persistence IndependentPersistent -Controller "SCSI controller 1"

 

db01、db02 両方に同じパスの VMDK ファイルが接続された状態になりました。

PS /home/gowatana> Get-VM db0? | Get-HardDisk | where {$_.Persistence -eq "IndependentPersistent"} | group Filename | select Count,@{N="VMs";E={($_.Group.Parent | Sort-Object)  -join ","}},Name | ft -AutoSize

 

Count VMs       Name

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

    2 db01,db02 [vsanDatastore-01] 60c4ab5a-6c3e-ca85-29da-b8aeedea7a23/db01_2.vmdk

    2 db01,db02 [vsanDatastore-01] 60c4ab5a-6c3e-ca85-29da-b8aeedea7a23/db01_3.vmdk

    2 db01,db02 [vsanDatastore-01] 60c4ab5a-6c3e-ca85-29da-b8aeedea7a23/db01_4.vmdk

    2 db01,db02 [vsanDatastore-01] 60c4ab5a-6c3e-ca85-29da-b8aeedea7a23/db01_5.vmdk

    2 db01,db02 [vsanDatastore-01] 60c4ab5a-6c3e-ca85-29da-b8aeedea7a23/db01_6.vmdk

    2 db01,db02 [vsanDatastore-01] 60c4ab5a-6c3e-ca85-29da-b8aeedea7a23/db01_7.vmdk

 

 

VMDK へのポリシー割り当て。(db02)

db02 では、まだ想定しているポリシーが割り当てられていません。

PS /home/gowatana> Get-VM db02 | Get-HardDisk | Get-SpbmEntityConfiguration | ft -AutoSize

 

Entity      Storage Policy    Status    Time Of Check

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

Hard disk 1 vsan-policy-raid5 compliant 2018/03/16 18:45:07

Hard disk 2 vsan-policy-raid5 compliant 2018/03/16 21:21:40

Hard disk 3                   none

Hard disk 4 vsan-policy-raid5 outOfDate 2018/03/17 2:11:59

Hard disk 5 vsan-policy-raid5 outOfDate 2018/03/17 2:12:15

Hard disk 6 vsan-policy-raid5 outOfDate 2018/03/17 2:12:32

Hard disk 7 vsan-policy-raid5 outOfDate 2018/03/17 2:12:48

Hard disk 8 vsan-policy-raid5 outOfDate 2018/03/17 2:13:05

 

 

ポリシーを割り当てます。

PS /home/gowatana> Get-VM db02 | Get-HardDisk | where {$_.Persistence -eq "IndependentPersistent"} | Set-SpbmEntityConfiguration -StoragePolicy vsan-policy-rac-01

 

ポリシーが割り当てれました。少しまつと Compliant になります。

PS /home/gowatana> Get-VM db02 | Get-HardDisk | Get-SpbmEntityConfiguration | ft -AutoSize

 

Entity      Storage Policy     Status    Time Of Check

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

Hard disk 1 vsan-policy-raid5  compliant 2018/03/16 18:45:07

Hard disk 2 vsan-policy-raid5  compliant 2018/03/16 21:21:40

Hard disk 3 vsan-policy-rac-01 compliant 2018/03/17 2:26:09

Hard disk 4 vsan-policy-rac-01 compliant 2018/03/17 2:26:16

Hard disk 5 vsan-policy-rac-01 compliant 2018/03/17 2:26:25

Hard disk 6 vsan-policy-rac-01 compliant 2018/03/17 2:26:32

Hard disk 7 vsan-policy-rac-01 compliant 2018/03/17 2:26:39

Hard disk 8 vsan-policy-rac-01 compliant 2018/03/17 2:26:47

 

 

VMDK への multi-writer 設定。(db01 / db02 両方)

コマンドひとつで multi-writer フラグを設定できないようなので、下記のように設定します。

まず Hard disk 3 だけ設定変更します。

PS /home/gowatana> $vm = Get-VM db01

PS /home/gowatana> $disk = $vm | Get-HardDisk -Name "Hard disk 3"

PS /home/gowatana> $spec = New-Object VMware.Vim.VirtualMachineConfigSpec

PS /home/gowatana> $spec.deviceChange = New-Object VMware.Vim.VirtualDeviceConfigSpec

PS /home/gowatana> $spec.deviceChange[0].operation = 'edit'

PS /home/gowatana> $spec.deviceChange[0].device = New-Object VMware.Vim.VirtualDisk

PS /home/gowatana> $spec.deviceChange[0].device = $disk.ExtensionData

PS /home/gowatana> $spec.deviceChange[0].device.Backing.Sharing = "sharingMultiWriter"

PS /home/gowatana> $vm.ExtensionData.ReconfigVM($spec)

 

設定されました。

PS /home/gowatana> Get-VM db01 | Get-HardDisk | select Parent,Name,@{N="Sharing";E={$_.ExtensionData.Backing.Sharing}}

 

Parent Name        Sharing

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

db01   Hard disk 1 sharingNone

db01   Hard disk 2 sharingNone

db01   Hard disk 3 sharingMultiWriter

db01   Hard disk 4 sharingNone

db01   Hard disk 5 sharingNone

db01   Hard disk 6 sharingNone

db01   Hard disk 7 sharingNone

db01   Hard disk 8 sharingNone

 

 

煩雑なので、下記のような PowerShell のファンクションを作成します。

function Set-MultiWriterFlag ($vm_name, $vdisk_name) {

    $vm = Get-VM $vm_name

    $disk = $vm | Get-HardDisk -Name $vdisk_name

    $spec = New-Object VMware.Vim.VirtualMachineConfigSpec

    $spec.deviceChange = New-Object VMware.Vim.VirtualDeviceConfigSpec

    $spec.deviceChange[0].operation = 'edit'

    $spec.deviceChange[0].device = New-Object VMware.Vim.VirtualDisk

    $spec.deviceChange[0].device = $disk.ExtensionData

    $spec.deviceChange[0].device.Backing.Sharing = "sharingMultiWriter"

    $vm.ExtensionData.ReconfigVM($spec)

}

 

ひたすら設定します。(db01)

PS /home/gowatana> function Set-MultiWriterFlag ($vm_name, $vdisk_name) {

>>     $vm = Get-VM $vm_name            

>>     $disk = $vm | Get-HardDisk -Name $vdisk_name

>>     $spec = New-Object VMware.Vim.VirtualMachineConfigSpec

>>     $spec.deviceChange = New-Object VMware.Vim.VirtualDeviceConfigSpec

>>     $spec.deviceChange[0].operation = 'edit'

>>     $spec.deviceChange[0].device = New-Object VMware.Vim.VirtualDisk

>>     $spec.deviceChange[0].device = $disk.ExtensionData

>>     $spec.deviceChange[0].device.Backing.Sharing = "sharingMultiWriter"

>>     $vm.ExtensionData.ReconfigVM($spec)

>> }

PS /home/gowatana> Set-MultiWriterFlag db01 "Hard disk 3"

PS /home/gowatana> Set-MultiWriterFlag db01 "Hard disk 4"

PS /home/gowatana> Set-MultiWriterFlag db01 "Hard disk 5"

PS /home/gowatana> Set-MultiWriterFlag db01 "Hard disk 6"

PS /home/gowatana> Set-MultiWriterFlag db01 "Hard disk 7"

PS /home/gowatana> Set-MultiWriterFlag db01 "Hard disk 8"

 

のこりの db02 も設定します。

PS /home/gowatana> Get-VM db02 | Get-HardDisk | where {$_.Persistence -eq "IndependentPersistent"} | % {Set-MultiWriterFlag $_.Parent.Name $_.Name}

 

設定されました。

PS /home/gowatana> Get-VM db0? | Get-HardDisk | select Parent,Name,@{N="Sharing";E={$_.ExtensionData.Backing.Sharing}} | Sort-Object Parent,Name

 

Parent Name        Sharing

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

db01   Hard disk 1 sharingNone

db01   Hard disk 2 sharingNone

db01   Hard disk 3 sharingMultiWriter

db01   Hard disk 4 sharingMultiWriter

db01   Hard disk 5 sharingMultiWriter

db01   Hard disk 6 sharingMultiWriter

db01   Hard disk 7 sharingMultiWriter

db01   Hard disk 8 sharingMultiWriter

db02   Hard disk 1 sharingNone

db02   Hard disk 2 sharingNone

db02   Hard disk 3 sharingMultiWriter

db02   Hard disk 4 sharingMultiWriter

db02   Hard disk 5 sharingMultiWriter

db02   Hard disk 6 sharingMultiWriter

db02   Hard disk 7 sharingMultiWriter

db02   Hard disk 8 sharingMultiWriter

 

 

DRS ルールの作成。

クラスタで DRS を有効にしているので、DRS ルールも設定しておきます。

アンチ アフィニティ ルールで、db01 と db02 が別の ESXi ホストで稼働するようにします。

 

アンチ アフィニティ ルールを作成します。

PS /home/gowatana> Get-Cluster vsan-cluster-01 | New-DrsRule -KeepTogether:$false -Name drs-anti-affinity-rac-01 -VM db01,db02

 

ルールが作成されました。

PS /home/gowatana> Get-Cluster vsan-cluster-01 | Get-DrsRule -Name drs-anti-affinity-rac-01 | select Cluster,Name,Type,Mandatory,Enabled,@{N="VMs";E={($_.VMIds | %{(Get-VM -Id $_).Name}) -join ","}}

 

 

Cluster   : vsan-cluster-01

Name      : drs-anti-affinity-rac-01

Type      : VMAntiAffinity

Mandatory : False

Enabled   : True

VMs       : db01,db02

 

 

VM の起動。

ここで VM を起動します。

PS /home/gowatana> Get-VM db0? | Start-VM

 

Name                 PowerState Num CPUs MemoryGB

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

db01                 PoweredOn  2        8.000

db02                 PoweredOn  2        8.000

 

 

Oracle RAC 構築。

Oracle Grid Infrastructure と Oracle Database をインストールして、RAC データベースを作成します。

(ここでは省略)

 

Oracle RAC のゲスト OS からみた VMDK の様子。

vSAN 上の VMDK ファイルによる仮想ディスクは、ゲスト OS から見ると VMFS にある仮想ディスクと同様に

「VMware Virtual disk」と認識されています。

[grid@db01 ~]$ cat /etc/oracle-release

Oracle Linux Server release 7.4

[grid@db01 ~]$ 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

[4:0:0:0]    disk    VMware   Virtual disk     2.0   /dev/sdc

[4:0:1:0]    disk    VMware   Virtual disk     2.0   /dev/sdd

[4:0:2:0]    disk    VMware   Virtual disk     2.0   /dev/sde

[4:0:3:0]    disk    VMware   Virtual disk     2.0   /dev/sdf

[4:0:4:0]    disk    VMware   Virtual disk     2.0   /dev/sdg

[4:0:5:0]    disk    VMware   Virtual disk     2.0   /dev/sdh

[grid@db01 ~]$

 

共有ディスクとして追加した 30GB のディスクは下記です。

[grid@db01 ~]$ lsblk -l /dev/sd[c-h]

NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT

sdc    8:32   0  30G  0 disk

sdd    8:48   0  30G  0 disk

sde    8:64   0  30G  0 disk

sdf    8:80   0  30G  0 disk

sdg    8:96   0  30G  0 disk

sdh    8:112  0  30G  0 disk

[grid@db01 ~]$

 

Oracle RAC の ASM で利用される Oracle ASM Filter Driver (ASMFD)では、

下記のようなラベルが付与されます。

[grid@db01 ~]$ asmcmd afd_lsdsk --all

node 'db01':

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

Label                     Filtering   Path

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

DATA1                       ENABLED   /dev/sdf

DATA2                       ENABLED   /dev/sdg

DATA3                       ENABLED   /dev/sdh

GRID1                       ENABLED   /dev/sdc

GRID2                       ENABLED   /dev/sde

GRID3                       ENABLED   /dev/sdd

node 'db02':

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

Label                     Filtering   Path

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

DATA1                       ENABLED   /dev/sdf

DATA2                       ENABLED   /dev/sdg

DATA3                       ENABLED   /dev/sdh

GRID1                       ENABLED   /dev/sdc

GRID2                       ENABLED   /dev/sde

GRID3                       ENABLED   /dev/sdd

[grid@db01 ~]$

 

/dev/sdc、/dev/sdd、/dev/sde で +GRID という ASM Disk Group、

/dev/sdf、/dev/sdg、/dev/sdh で +DATA という ASM Disk Group を構成してあります。

今回の例では微妙な感じになっていますが、/dev/sd? のデバイス名は永続的なものではないので、

Linux OS の再起動で別の名前に変わったりします。

仮想ハードディスクと ゲストOSのデバイス名をうまく対応させるには

最初にディスク認識させたときに識別して ASMFD のラベル付けをする必要があります。

[grid@db01 ~]$ export ORACLE_SID=+ASM1

[grid@db01 ~]$ sqlplus / as sysdba

 

SQL*Plus: Release 12.2.0.1.0 Production on 日 3月 18 03:20:34 2018

 

Copyright (c) 1982, 2016, Oracle.  All rights reserved.

 

Connected to:

Oracle Database 12c Enterprise Edition Release 12.2.0.1.0 - 64bit Production

 

SQL> set line 120

SQL> col label for a10

SQL> col path for a10

SQL> col DG_NAME for a10

SQL> select dg.NAME as DG_NAME,d.DISK_NUMBER,LABEL,PATH,d.TOTAL_MB from v$asm_disk d,v$asm_diskgroup dg where d.GROUP_NUMBER = dg.GROUP_NUMBER and d.TOTAL_MB > 0;

 

DG_NAME    DISK_NUMBER LABEL      PATH         TOTAL_MB

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

GRID                 0 GRID1      AFD:GRID1       30720

GRID                 1 GRID2      AFD:GRID2       30720

GRID                 2 GRID3      AFD:GRID3       30720

DATA                 0 DATA1      AFD:DATA1       30720

DATA                 1 DATA2      AFD:DATA2       30720

DATA                 2 DATA3      AFD:DATA3       30720

 

6 rows selected.

 

SQL>

 

ちなみに、2 ノードでの 12c R2 RAC では下記のようなリソース構成になります。

[grid@db01 ~]$ crsctl stat res -t

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

Name           Target  State        Server                   State details

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

Local Resources

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

ora.ASMNET1LSNR_ASM.lsnr

               ONLINE  ONLINE       db01                     STABLE

               ONLINE  ONLINE       db02                     STABLE

ora.DATA.dg

               ONLINE  ONLINE       db01                     STABLE

               ONLINE  ONLINE       db02                     STABLE

ora.GRID.dg

               ONLINE  ONLINE       db01                     STABLE

               ONLINE  ONLINE       db02                     STABLE

ora.LISTENER.lsnr

               ONLINE  ONLINE       db01                     STABLE

               ONLINE  ONLINE       db02                     STABLE

ora.chad

               ONLINE  ONLINE       db01                     STABLE

               ONLINE  ONLINE       db02                     STABLE

ora.net1.network

               ONLINE  ONLINE       db01                     STABLE

               ONLINE  ONLINE       db02                     STABLE

ora.ons

               ONLINE  ONLINE       db01                     STABLE

               ONLINE  ONLINE       db02                     STABLE

ora.proxy_advm

               OFFLINE OFFLINE      db01                     STABLE

               OFFLINE OFFLINE      db02                     STABLE

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

Cluster Resources

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

ora.LISTENER_SCAN1.lsnr

      1        ONLINE  ONLINE       db01                     STABLE

ora.MGMTLSNR

      1        ONLINE  ONLINE       db01                     169.254.131.137 192.

                                                             168.41.171,STABLE

ora.asm

      1        ONLINE  ONLINE       db01                     Started,STABLE

      2        ONLINE  ONLINE       db02                     Started,STABLE

      3        OFFLINE OFFLINE                               STABLE

ora.cvu

      1        ONLINE  ONLINE       db01                     STABLE

ora.db01.vip

      1        ONLINE  ONLINE       db01                     STABLE

ora.db02.vip

      1        ONLINE  ONLINE       db02                     STABLE

ora.mgmtdb

      1        ONLINE  ONLINE       db01                     Open,STABLE

ora.orcl.db

      1        ONLINE  ONLINE       db01                     Open,HOME=/u01/app/o

                                                             racle/product/12.2.0

                                                             /dbhome_1,STABLE

      2        ONLINE  ONLINE       db02                     Open,HOME=/u01/app/o

                                                             racle/product/12.2.0

                                                             /dbhome_1,STABLE

ora.qosmserver

      1        ONLINE  ONLINE       db01                     STABLE

ora.scan1.vip

      1        ONLINE  ONLINE       db01                     STABLE

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

[grid@db01 ~]$

 

このなかで、共有ディスクの ASM Disk Group (+DATA、+GRID)のリソースは下記の部分です。

[grid@db01 ~]$ crsctl stat res -w '(TYPE = ora.diskgroup.type)' -t

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

Name           Target  State        Server                   State details

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

Local Resources

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

ora.DATA.dg

               ONLINE  ONLINE       db01                     STABLE

               ONLINE  ONLINE       db02                     STABLE

ora.GRID.dg

               ONLINE  ONLINE       db01                     STABLE

               ONLINE  ONLINE       db02                     STABLE

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

[grid@db01 ~]$

 

以上、PowerCLI で Oracle RAC むけ VM を設定してみる話でした。

PowerCLI を利用して、Oracle RAC 用に構成した vSphere / vSAN 環境の VM の情報を確認してみます。

 

vSphere / vSAN 環境に Oracle RAC を構築する場合に、いくつか VM に RAC むけの設定をします。

RAC の構築目的によって具体的な設定値は変わりますが、たとえば下記のような設定です。

  • vNICの数や、接続するネットワークを揃える。
  • 仮想ハード ディスク の VMDK ファイルを複数の VM で共有する。
  • VMDK ファイルは EagerZeroed Thick にして「Multi Writer フラグ」を設定する。
    (参考: https://kb.vmware.com/kb/2121181
  • 共有ディスクむけに容量を 100%予約する「仮想マシン ストレージ ポリシー」を作成する。
  • Oracle RAC のクラスタに参加している VM 同士を DRS のアンチ アフィニティ ルールで分割配置する。

など・・・

 

VM の設定項目が多いため、私のラボでは何か忘れていないか気づきやすいように

PowerCLI を利用して設定確認しています。

 

下記のようなスクリプトを作成しています。

get_rac-vm_info.ps1 · GitHub

  • ファイルは UTF-8(with BOM)で保存すると無難かなとおもいます。
  • 実行するときは、PowerShell / PowerCLI のウィンドウ幅を 100 くらいにしておくとよいです。

 

今回は、Windows で PowerCLI 10.0 を利用しています。

PowerCLI> Get-Module VMware.* | select Version,Name | Sort-Object

 

Version        Name

-------        ----

10.0.0.7893910 VMware.VimAutomation.Sdk

10.0.0.7894167 VMware.VimAutomation.Storage

10.0.0.7893909 VMware.VimAutomation.Core

10.0.0.7893915 VMware.VimAutomation.Cis.Core

10.0.0.7893906 VMware.VimAutomation.Common

 

 

PowerCLI>

 

スクリプトの実行前に、vCenter に接続しておきます。

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

 

私のラボの RAC (db01 / db02 で 2ノード構成)で情報取得してみると、下記のようになっています。

vmx-13 の仮想マシンなので、OSTyep は「Oracle Linux 7 (64-bit)」にしています。

ESXi 6.5 での Guest OS の細分化について。(Oracle Linux 7 など)

PowerCLI> .\get_rac-vm_info.ps1 db01,db02

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

vCPU / vRAM

 

VM   PowerState NumCpu MemoryGB HwVersion OSType

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

db01  PoweredOn      2        8 vmx-13    Oracle Linux 7 (64-bit)

db02  PoweredOn      2        8 vmx-13    Oracle Linux 7 (64-bit)

 

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

Cluster

 

Cluster     : vsan-cluster-01

VsanEnabled : True

HAEnabled   : True

DrsEnabled  : True

EVCMode     : intel-haswell

 

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

Host

 

VM   Cluster         ESXi

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

db01 vsan-cluster-01 hv-i22.go-lab.jp

db02 vsan-cluster-01 hv-i21.go-lab.jp

 

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

vNIC

 

VM   Name                 Type NetworkName          StartConnected Connected

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

db01 Network adapter 1 Vmxnet3 dvpg-vds01-vlan-1011           True      True

db01 Network adapter 2 Vmxnet3 dvpg-vds01-vlan-4001           True      True

db02 Network adapter 1 Vmxnet3 dvpg-vds01-vlan-1011           True      True

db02 Network adapter 2 Vmxnet3 dvpg-vds01-vlan-4001           True      True

 

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

vSCSI Controller

 

VM   Name                     Type BusSharingMode UnitNumber ControllerKey

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

db01 SCSI controller 0 ParaVirtual      NoSharing          3          1000

db01 SCSI controller 1 ParaVirtual      NoSharing          4          1001

db02 SCSI controller 0 ParaVirtual      NoSharing          3          1000

db02 SCSI controller 1 ParaVirtual      NoSharing          4          1001

 

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

vDisk

 

VM   Name        Controller GB    StorageFormat           Persistence Sharing

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

db01 Hard disk 1       1000 16             Thin            Persistent sharingNone

db01 Hard disk 2       1000 40             Thin            Persistent sharingNone

db01 Hard disk 3       1001 30 EagerZeroedThick IndependentPersistent sharingMultiWriter

db01 Hard disk 4       1001 30 EagerZeroedThick IndependentPersistent sharingMultiWriter

db01 Hard disk 5       1001 30 EagerZeroedThick IndependentPersistent sharingMultiWriter

db01 Hard disk 6       1001 30 EagerZeroedThick IndependentPersistent sharingMultiWriter

db01 Hard disk 7       1001 30 EagerZeroedThick IndependentPersistent sharingMultiWriter

db01 Hard disk 8       1001 30 EagerZeroedThick IndependentPersistent sharingMultiWriter

db02 Hard disk 1       1000 16             Thin            Persistent sharingNone

db02 Hard disk 2       1000 40             Thin            Persistent sharingNone

db02 Hard disk 3       1001 30 EagerZeroedThick IndependentPersistent sharingMultiWriter

db02 Hard disk 4       1001 30 EagerZeroedThick IndependentPersistent sharingMultiWriter

db02 Hard disk 5       1001 30 EagerZeroedThick IndependentPersistent sharingMultiWriter

db02 Hard disk 6       1001 30 EagerZeroedThick IndependentPersistent sharingMultiWriter

db02 Hard disk 7       1001 30 EagerZeroedThick IndependentPersistent sharingMultiWriter

db02 Hard disk 8       1001 30 EagerZeroedThick IndependentPersistent sharingMultiWriter

 

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

Share vDisk

 

vDisk : Hard disk 3

Name  : [vsanDatastore-01] 60c4ab5a-6c3e-ca85-29da-b8aeedea7a23/db01_2.vmdk

VMs   : 2

VM    : db01,db02

 

vDisk : Hard disk 4

Name  : [vsanDatastore-01] 60c4ab5a-6c3e-ca85-29da-b8aeedea7a23/db01_3.vmdk

VMs   : 2

VM    : db01,db02

 

vDisk : Hard disk 5

Name  : [vsanDatastore-01] 60c4ab5a-6c3e-ca85-29da-b8aeedea7a23/db01_4.vmdk

VMs   : 2

VM    : db01,db02

 

vDisk : Hard disk 6

Name  : [vsanDatastore-01] 60c4ab5a-6c3e-ca85-29da-b8aeedea7a23/db01_5.vmdk

VMs   : 2

VM    : db01,db02

 

vDisk : Hard disk 7

Name  : [vsanDatastore-01] 60c4ab5a-6c3e-ca85-29da-b8aeedea7a23/db01_6.vmdk

VMs   : 2

VM    : db01,db02

 

vDisk : Hard disk 8

Name  : [vsanDatastore-01] 60c4ab5a-6c3e-ca85-29da-b8aeedea7a23/db01_7.vmdk

VMs   : 2

VM    : db01,db02

 

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

VM Storage Policy

 

VM   vDisk       StoragePolicy      ComplianceStatus

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

db01 Hard disk 1 vsan-policy-raid5         compliant

db01 Hard disk 2 vsan-policy-raid5         compliant

db01 Hard disk 3 vsan-policy-rac-01        compliant

db01 Hard disk 4 vsan-policy-rac-01        compliant

db01 Hard disk 5 vsan-policy-rac-01        compliant

db01 Hard disk 6 vsan-policy-rac-01        compliant

db01 Hard disk 7 vsan-policy-rac-01        compliant

db01 Hard disk 8 vsan-policy-rac-01        compliant

db02 Hard disk 1 vsan-policy-raid5         compliant

db02 Hard disk 2 vsan-policy-raid5         compliant

db02 Hard disk 3 vsan-policy-rac-01        compliant

db02 Hard disk 4 vsan-policy-rac-01        compliant

db02 Hard disk 5 vsan-policy-rac-01        compliant

db02 Hard disk 6 vsan-policy-rac-01        compliant

db02 Hard disk 7 vsan-policy-rac-01        compliant

db02 Hard disk 8 vsan-policy-rac-01        compliant

 

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

Storage Policy Setting

 

StoragePolicy      Capability                                                 Value

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

vsan-policy-rac-01 VSAN.proportionalCapacity                                    100

vsan-policy-rac-01 VSAN.hostFailuresToTolerate                                    1

vsan-policy-rac-01 VSAN.stripeWidth                                               2

vsan-policy-raid5  VSAN.replicaPreference      RAID-5/6 (Erasure Coding) - Capacity

vsan-policy-raid5  VSAN.proportionalCapacity                                      0

 

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

DRS Affinity Rule

 

Cluster   : vsan-cluster-01

Name      : drs-anti-affinity-rac-01

Type      : VMAntiAffinity

Mandatory : False

Enabled   : True

VMs       : db01,db02

 

PowerCLI>

 

vSAN 環境に RAC を構築した場合でも VM の構成は VMFS データストアの場合とあまり変わりませんが、

VMDK は EagerZeroed Thick にして、さらに「仮想マシン ストレージ ポリシー」で

オブジェクトの容量予約を 100% にしておきます。

 

Oracle RAC では(ゲスト)OS の iSCSI Initiator から

直接接続した iSCSI デバイスを共有ディスクとして利用することもできます。

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

現時点(2018年3月)では物理マシンでの RAC のみを対象としているようです。

そして vSAN では RDM には対応しないので

ゲスト OS で RAC を構築するときには VMDK 共有をすることになるはずです。

 

下記の KB に制限が記載されていました。

 

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

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

制限

  • 現在、Microsoft クラスタの実装ではサポートされていません。
  • 現在、他の vSphere ホストのターゲットとしての使用はサポートされていません。
  • 現在、サードパーティのハイパーバイザーでの使用はサポートされていません。
  • 現在、仮想マシンでの使用はサポートされていません。

 

また、VMware から vSAN + Oracle RAC についてのドキュメントも公開されているので、

本番環境(デモ/開発むけのラボ環境ではなく)での構築となる場合には確認しておくとよいと思います。

 

Oracle Real Application Clusters on VMware vSAN

https://storagehub.vmware.com/t/vmware-vsan/oracle-real-application-clusters-on-vmware-virtual-san/

 

以上、PowerCLI を利用した Oracle RAC VM の情報取得例でした。

前回、HCIBench の設定を Ansible で自動化してみる話を投稿しました。

HCIBench の設定を Ansible で自動化してみる。

 

今回は、設定後のテスト実行にコマンドライン / Ansible を利用してみます。

 

HCIBench のコマンドラインでのテスト実行。

HCIBench をコマンドラインで実行する方法については、

下記のブログで紹介されています。

Use HCIBench Like a Pro – Part 2 - Virtual Blocks

 

まず、HCIBench の Photon OS に SSH でログインします。

HCIBench の仮想アプライアンスは「hci-bench02.go-lab.jp」というアドレスで用意しています。

[gowatana@client01 ~]$ ssh -l root hci-bench02.go-lab.jp

############################################

#                                          #

#        Welcome to HCIBench 1.6.6         #

#                                          #

############################################

root@photon-HCIBench [ ~ ]#

 

今回は、HCIBench で使用する設定ファイルは配置ずみです。

root@photon-HCIBench [ ~ ]# cat /opt/automation/conf/perf-conf.yaml

vc: 'vc-sv01.go-lab.jp'

vc_username: 'hci-bench-connect'

vc_password: 'パスワード'

datacenter_name: 'dc01'

cluster_name: 'vsan-cluster-01'

network_name: 'dvpg-vds01-vlan-1012'

static_enabled: false

reuse_vm: false

datastore_name:

- 'vsanDatastore-01'

deploy_on_hosts: false

hosts:

host_username:

host_password:

vm_prefix: 'vdbench'

easy_run: false

clear_cache: false

number_vm: 2

number_data_disk: 2

size_data_disk: 1

self_defined_param_file_path: '/opt/tmp/tmp20180315144339'

output_path: 'TEST_vsan-cluster-01_case-101'

warm_up_disk_before_testing: 'NONE'

testing_duration:

cleanup_vm: false

root@photon-HCIBench [ ~ ]# file /opt/automation/vdbench-param-files/*

/opt/automation/vdbench-param-files/vdb-case-101: ASCII text

root@photon-HCIBench [ ~ ]#

 

Web UI にある「Varidate」ボタンにかわるスクリプトの実行してみます。

ちなみに出力結果をみると、テスト対象が 6 ノード vSAN クラスタだということもわかります。

※ここでのタイムスタンプは JST ではないので読みかえることになります。

root@photon-HCIBench [ ~ ]# /opt/automation/pre-validate-config.sh

2018-03-15 15:01:07 -0700: Validating VC IP and Crendetial...

2018-03-15 15:01:10 -0700: VC IP and Credential Validated

2018-03-15 15:01:10 -0700: Validating Datacenter dc01...

2018-03-15 15:01:11 -0700: Datacenter dc01 Validated

2018-03-15 15:01:11 -0700: Validating Cluster vsan-cluster-01...

2018-03-15 15:01:12 -0700: Cluster vsan-cluster-01 Validated

2018-03-15 15:01:12 -0700: Cluster vsan-cluster-01 has DRS mode: fullyAutomated

2018-03-15 15:01:12 -0700: Validating If Hosts in Cluster vsan-cluster-01 Could be Connected...

2018-03-15 15:01:25 -0700: All Hosts could be Connected

2018-03-15 15:01:25 -0700: Validating If Any Hosts in Cluster vsan-cluster-01 is in Maintainance Mode...

2018-03-15 15:01:26 -0700: All the Hosts in Cluster vsan-cluster-01 are not in Maitainance Mode

2018-03-15 15:01:26 -0700: Validating Network dvpg-vds01-vlan-1012...

2018-03-15 15:01:28 -0700: Network dvpg-vds01-vlan-1012 Validated

2018-03-15 15:01:28 -0700: Checking If Network dvpg-vds01-vlan-1012 is accessible from all the hosts of vsan-cluster-01...

2018-03-15 15:01:29 -0700: Network dvpg-vds01-vlan-1012 is accessible from host hv-i22.go-lab.jp

2018-03-15 15:01:30 -0700: Network dvpg-vds01-vlan-1012 is accessible from host hv-i25.go-lab.jp

2018-03-15 15:01:31 -0700: Network dvpg-vds01-vlan-1012 is accessible from host hv-i21.go-lab.jp

2018-03-15 15:01:31 -0700: Network dvpg-vds01-vlan-1012 is accessible from host hv-i24.go-lab.jp

2018-03-15 15:01:32 -0700: Network dvpg-vds01-vlan-1012 is accessible from host hv-i26.go-lab.jp

2018-03-15 15:01:33 -0700: Network dvpg-vds01-vlan-1012 is accessible from host hv-i23.go-lab.jp

2018-03-15 15:01:33 -0700: Network dvpg-vds01-vlan-1012 is accessible from all the hosts of vsan-cluster-01

2018-03-15 15:01:33 -0700: Validating Type of Network dvpg-vds01-vlan-1012...

2018-03-15 15:01:34 -0700: Network dvpg-vds01-vlan-1012 Type is DistributedVirtualPortgroup

2018-03-15 15:01:34 -0700: Validating cluster inter-connectivity...

2018-03-15 15:03:20 -0700: Cluster inter-connectivity validated

2018-03-15 15:03:23 -0700: Validating Datastore vsanDatastore-01...

2018-03-15 15:03:24 -0700: Datastore vsanDatastore-01 Validated

2018-03-15 15:03:24 -0700: Checking Datastore vsanDatastore-01 type...

2018-03-15 15:03:24 -0700: Datastore vsanDatastore-01 type is vsan

2018-03-15 15:03:24 -0700: Checking If Datastore vsanDatastore-01 is accessible from all the hosts of vsan-cluster-01...

2018-03-15 15:03:25 -0700: Datastore vsanDatastore-01 is accessible from host hv-i22.go-lab.jp

2018-03-15 15:03:25 -0700: Datastore vsanDatastore-01 is accessible from host hv-i25.go-lab.jp

2018-03-15 15:03:25 -0700: Datastore vsanDatastore-01 is accessible from host hv-i21.go-lab.jp

2018-03-15 15:03:25 -0700: Datastore vsanDatastore-01 is accessible from host hv-i24.go-lab.jp

2018-03-15 15:03:25 -0700: Datastore vsanDatastore-01 is accessible from host hv-i26.go-lab.jp

2018-03-15 15:03:25 -0700: Datastore vsanDatastore-01 is accessible from host hv-i23.go-lab.jp

2018-03-15 15:03:25 -0700: Datastore vsanDatastore-01 is accessible from all the hosts of vsan-cluster-01

2018-03-15 15:03:25 -0700: Validating If VSAN Enabled in Cluster vsan-cluster-01...

2018-03-15 15:03:30 -0700: VSAN is Enabled in Cluster vsan-cluster-01, the VSAN Datastore name is vsanDatastore-01, capacity is 5589 GB and freespace is 4238 GB, the default policy is vsan-policy-raid5

2018-03-15 15:03:31 -0700: Deploy on hosts: False. Skip validating hosts...

2018-03-15 15:03:31 -0700: Validating Vdbench binary and the workload profiles...

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

2018-03-15 15:03:32 -0700: All the config has been validated, please go ahead to kick off testing

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

Caution:

You have 2 VM Have the Same Prefix as vdbench, Please Make Sure the VMs are OK to be Deleted Otherwise Please Change the VM Name Prefix.

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

root@photon-HCIBench [ ~ ]#

 

ちょうどテスト VM がすでにあるという注意メッセージがあるので、

VM のクリーンアップをしてみます。

root@photon-HCIBench [ ~ ]# /opt/automation/cleanup-vm.sh

Starting Cleaning VDBench Guest VMs...

VDBench Guest VMs Deleted

root@photon-HCIBench [ ~ ]#

 

ベンチマーク テストを実行します。

コマンドラインを実行すると、プロンプトがすくに戻されます。

root@photon-HCIBench [ ~ ]# /opt/automation/start-testing.sh

root@photon-HCIBench [ ~ ]#

 

実行の様子は、下記のようにログファイルから確認できます。

root@photon-HCIBench [ ~ ]# tail -f /opt/automation/logs/test-status.log

Deployment Started.

Verifying If VMs are Accessible

Deployment Successfully Finished.

I/O Test Started.

Started Testing vdb-case-101

Done Testing vdb-case-101

I/O Test Finished.

Testing Finished

 

テストが終了すると、下記のようなログファイルが出力されています。

root@photon-HCIBench [ ~ ]# ls -ltr /opt/automation/logs/

total 44

drwxrwxr-x 2 root root  4096 Mar 15 15:01 prevalidation

-rw-rw-r-- 1 root root   390 Mar 15 15:20 vm-cleanup.log

-rw-rw-r-- 1 root root 16321 Mar 15 15:24 vc-vc-sv01.go-lab.jp-vs-vm-deploy-0.log

-rw-rw-r-- 1 root root   696 Mar 15 15:24 deploy.log

-rw-rw-r-- 1 root root  6379 Mar 15 15:31 io-test-vdb-case-101.log

-rw-rw-r-- 1 root root  1184 Mar 15 15:31 vdbench-testing.log

-rw-rw-r-- 1 root root   195 Mar 15 15:31 test-status.log

root@photon-HCIBench [ /opt/automation/logs ]#

 

テストの進行は Web ブラウザからでも確認できます。

URL は下記のようになっています。

http://  HCIBench のアドレス /hcibench_logs/test-status.log

hci-bench-start-testing-01.png

 

「Testing Finished」があると、ベンチマークが終了しています。

通常の Web UI からの実行時と同様に、レポートが生成されています。

hci-bench-start-testing-02.png

 

レポートは、下記のようにまとめて採取することもできます。

[gowatana@client01 work]$ scp -pr root@hci-bench02.go-lab.jp:/opt/output/results/TEST_vsan-cluster-01_case-101 .

[gowatana@client01 work]$ ls TEST_vsan-cluster-01_case-101/

vdb-case-101-1521152685  vdb-case-101-1521152685-res.txt

 

HCIBench の Ansible でのテスト実行。

Ansible でテストを実行する場合は、shell モジュールなどが利用できます。

ここでは、例として Ansible の Playbook に記載したコマンド ラインを実行してみます。

 

まず、HCIBench の ホスト(ホスト名か、アドレスか)を記載した

Ansible のインベントリファイルを用意しておきます。

[gowatana@client01 hci-bench-config]$ cat hosts

hci-bench01.go-lab.jp

 

そして、下記のような YAML ファイルを用意しています。

Playbook の内容はただ 1行のコマンドラインを実行するだけなので

これだけだと Ansible を利用する意義はありません。

しかし、すでに Ansible を活用していたり、HCIBench の設定にも Ansible を利用するような場合は

環境の構成管理からベンチマーク テストの実行までツールを一貫させることができると思います。

[gowatana@client01 hci-bench-config]$ cat start-testing.yml

---

- name: HCI Bench start testing

  hosts: all

  remote_user: root

 

  tasks:

  - name: start testing

    shell: /opt/automation/start-testing.sh

 

 

ansible-playbook コマンドを実行します。

[gowatana@client01 hci-bench-config]$ ansible-playbook -i hosts start-testing.yml

 

PLAY [HCI Bench start testing] *************************************************

 

TASK [Gathering Facts] *********************************************************

ok: [hci-bench01.go-lab.jp]

 

TASK [start testing] ***********************************************************

changed: [hci-bench01.go-lab.jp]

 

PLAY RECAP *********************************************************************

hci-bench01.go-lab.jp      : ok=2    changed=1    unreachable=0    failed=0

 

[gowatana@client01 hci-bench-config]$

 

今回の Playbook にはテストの進行確認は含めていないため、curl で確認してしまいます。

[gowatana@client01 hci-bench-config]$ curl -s http://hci-bench01.go-lab.jp/hcibench_logs/test-status.log

Deployment Started.

 

ベンチマークテストの進行状況はログ出力され・・・

[gowatana@client01 hci-bench-config]$ curl -s http://hci-bench01.go-lab.jp/hcibench_logs/test-status.log

Deployment Started.

Verifying If VMs are Accessible

Deployment Successfully Finished.

I/O Test Started.

 

「Testing Finished」が出力されれば終了です。

[gowatana@client01 hci-bench-config]$ curl -s http://hci-bench01.go-lab.jp/hcibench_logs/test-status.log

Deployment Started.

Verifying If VMs are Accessible

Deployment Successfully Finished.

I/O Test Started.

I/O Test Finished.

Testing Finished

 

HCIBench 自体は vSAN に限らず、vSphere(vCenter / ESXi)環境であれば利用できるので、

できるだけベンチマーク 環境を自動化しておくと便利ではないかなと思います。

また、このような仕組みを利用すれば、構築作業後の確認や

他のベンチマークツールとの連携などにも利用できそうかなと思います。

 

これまでの HCIBench 利用の工夫については、下記もどうぞ。

HCIBench の OVA を PowerCLI でデプロイする。

HCIBench の設定を Ansible で自動化してみる。

 

以上、HCIBench のベンチマーク テストの実行を工夫してみる話でした。

最近 PowerCLI 10.0 が公開されましたが、とうとう vmware/powerclicore の

Docker コンテナもイメージもアップデートされました。

PowerCLI Docker Image Updated - VMware PowerCLI Blog - VMware Blogs

 

PowerCLI 10.0 は Linux / macOS もサポートされるようになり、

少し前に Linux で実行してみた投稿をしてみましたが・・・

Linux で PowerCLI 10.0 をためしてみる。

 

今回は macOS で PowerCLI 10.0 の Docker コンテナを起動してみます。

 

実行環境。

普段あまり使っていない MacBook なのでバージョンは若干古いかもしれません。

 

macOS です。

gomac:~ gowatana$ sw_vers

ProductName: Mac OS X

ProductVersion: 10.13.2

BuildVersion: 17C205

 

Docker です。

gomac:~ gowatana$ docker version

Client:

Version:      17.09.1-ce

API version:  1.32

Go version:   go1.8.3

Git commit:   19e2cf6

Built:        Thu Dec  7 22:22:25 2017

OS/Arch:      darwin/amd64

 

Server:

Version:      17.09.1-ce

API version:  1.32 (minimum version 1.12)

Go version:   go1.8.3

Git commit:   19e2cf6

Built:        Thu Dec  7 22:28:28 2017

OS/Arch:      linux/amd64

Experimental: false

 

コンテナの起動。

コンテナのイメージは、vmware/powerclicore です。

https://hub.docker.com/r/vmware/powerclicore/

 

イメージを pull します。タグは特に指定せず latest です。

gomac:~ gowatana$ docker image pull vmware/powerclicore

Using default tag: latest

latest: Pulling from vmware/powerclicore

e9b1ffebdf09: Pull complete

1ca0671214e4: Pull complete

e2054d0e7b6e: Pull complete

9e5896375981: Pull complete

4fda4ed0aa8e: Pull complete

ae595f021807: Pull complete

2223c2963494: Pull complete

c0625c88535b: Pull complete

Digest: sha256:4c19d7f6e5b460cdcea403977f1e8491f5c28c81a60e84dddf9d65921ba3ac51

Status: Downloaded newer image for vmware/powerclicore:latest

 

コンテナを起動します。

事情により --dns でコンテナが参照する DNS サーバのアドレスを指定しています。

( macOS で利用している DHCP と自宅ラボの DNS サーバのアドレスがあっていないので・・・)

gomac:~ gowatana$ docker container run -it --rm --dns=192.168.1.254 vmware/powerclicore

PowerShell v6.0.1

Copyright (c) Microsoft Corporation. All rights reserved.

 

https://aka.ms/pscore6-docs

Type 'help' to get help.

 

PS /root>

 

コンテナは、Photon OS 2.0 をベースにされています。

PS /root> cat /etc/photon-release

VMware Photon OS 2.0

PHOTON_BUILD_NUMBER=304b817

 

自宅ラボの vCenter は証明書を入れ替えていないので、

証明書エラーを無視してしまいます。

PS /root> Set-PowerCLIConfiguration -InvalidCertificateAction:Ignore -Confirm:$false

 

PowerShell モジュールの様子です。

Cmds 列は、それぞれのモジュールに含まれるコマンド数のはずです。

PS /root> Get-Module -ListAvailable | select @{N="Cmds";E={$_.ExportedCommands.Count}},Version,Name | Sort-Object Name

 

Cmds Version        Name

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

   1 0.0            apply-hardening

   3 0.0            Backup-VCSA

   9 0.0            ContentLibrary

   6 0.0            DatastoreFunctions

   1 0.0            Get-NewAndRemovedVMs

   1 0.0            Get-NICDetails

   1 0.0            Get-VMmaxIOPS

   1 0.0            Konfig-ESXi

   2 3.0.0.0        Microsoft.PowerShell.Host

  43 3.1.0.0        Microsoft.PowerShell.Management

   6 3.0.0.0        Microsoft.PowerShell.Security

103 3.1.0.0        Microsoft.PowerShell.Utility

   8 1.0.0.0        NSXT

  13 1.1.7.0        PackageManagement

300 3.0.1091       PowerNSX

  29 1.6.0          PowerShellGet

119 3.1.1          PowervRA

   7 0.0            ProactiveHA

  71 0.0            PSDesiredStateConfiguration

   6 1.2            PSReadLine

   1 0.0            PSvLIMessage

   1 0.0            Recommend-Sizing

   1 0.0            Set-CBT

   1 0.0            Start-UNMAP

  16 0.0            VAMI

   5 0.0            vCenter.Alarms

  10 0.0            vCenterManualMigration

   5 0.0            VCHA

  11 1.0            Vi-Module

   2 0.0            VMCPFunctions

   3 1.0.0.0        VMFSIncrease

  11 0.0            VMToolsManagement

   5 1.0.0          VMware-vCD-Module

   3 1.0.2          VMware-vCD-TenantReport

  27 6.5.2.7812840  VMware.DeployAutomation

  15 1.0.0.0        VMware.Hosted

  12 6.5.2.7812840  VMware.ImageBuilder

   0 10.0.0.7895300 VMware.PowerCLI

   3 10.0.0.7893915 VMware.VimAutomation.Cis.Core

106 10.0.0.7893901 VMware.VimAutomation.Cloud

   0 10.0.0.7893906 VMware.VimAutomation.Common

302 10.0.0.7893909 VMware.VimAutomation.Core

   1 6.5.4.7567193  VMware.VimAutomation.HA

   2 7.1.0.7547311  VMware.VimAutomation.HorizonView

   1 10.0.0.7893904 VMware.VimAutomation.License

   3 10.0.0.7893913 VMware.VimAutomation.Nsxt

   4 10.0.0.7893924 VMware.VimAutomation.PCloud

   2 10.0.0.7893910 VMware.VimAutomation.Sdk

   2 10.0.0.7893900 VMware.VimAutomation.Srm

  92 10.0.0.7894167 VMware.VimAutomation.Storage

   1 1.2.0.0        VMware.VimAutomation.StorageUtility

  32 10.0.0.7893903 VMware.VimAutomation.Vds

   5 10.0.0.7893902 VMware.VimAutomation.Vmc

  12 10.0.0.7893921 VMware.VimAutomation.vROps

  16 1.2.0          VMware.VMC

  19 1.0            VMware.VMEncryption

  19 6.5.1.7862888  VMware.VumAutomation

   3 0.0            vSphere_Hardening_Assess_VM_v1a

 

PS /root>

 

Dockerfile を見ると、PowerNSX と PowervRA もインストールされていることがわかります。

そして、vSAN むけのモジュールも PowerCLI に含まれています。

powerclicore/Dockerfile at master · vmware/powerclicore · GitHub

 

vCenter / NSX Manger に接続してみる。

それでは vCenter「vc-sv01.go-lab.jp」に接続します。

すでに InvalidCertificateAction の設定をしているので、エラーが抑止されています。

PS /root> Connect-VIServer vc-sv01.go-lab.jp

Specify Credential

Please specify server credential

User: gowatana

Password for user gowatana: **********

 

 

Name                           Port  User     

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

vc-sv01.go-lab.jp              443   GO-LAB\gowatana

 

 

PS /root>

 

下記のように vSAN むけのコマンドも実行できます。

PS /root> Get-VsanClusterConfiguration | Sort-Object Cluster

 

 

Cluster              VsanEnabled  IsStretchedCluster   Last HCL Updated

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

ha-cluster-01        False        False

ha-cluster-02        False        False

vsan-cluster-01      True         False                01/28/2018 12:01:23

vsan-cluster-02      True         False                01/28/2018 12:01:23

vsan-cluster-03      True         True                 01/28/2018 12:01:23

work-cluster-01      False        False

 

PS /root>

 

PowerNSX も含まれています。

NSX Manager に接続してみました。

PS /root> Connect-NsxServer -vCenterServer vc-sv01.go-lab.jp

 

PowerShell credential request

vCenter Server SSO Credentials

User: gowatana

Password for user gowatana: **********

 

Using existing PowerCLI connection to 192.168.1.95

 

 

Version             : 6.4.0

BuildNumber         : 7564187

Credential          : System.Management.Automation.PSCredential

Server              : 192.168.1.140

Port                : 443

Protocol            : https

UriPrefix           :

ValidateCertificate : False

VIConnection        : vc-sv01.go-lab.jp

DebugLogging        : False

DebugLogfile        : \PowerNSXLog-gowatana@-2018_03_15_11_10_47.log

 

 

PS /root>

 

macOS 自体に PowerShell / PowerCLI 10.0 をインストールすることも可能になりましたが、

Docker コンテナであれば PowerShell モジュールのインストールよりも、さらに手軽に実行できるはずです。

また、多くの PowerShell モジュールがインストールされてカオス環境になることを避けたり、

将来的に複数の PowerCLI バージョンをきれいに使い分けたり、といった使い方ができそうです。

 

以上、PowerCLI 10.0 の Docker コンテナを起動してみる話でした。