Skip navigation
1 2 3 Previous Next

にほんごVMware

371 posts

VMware Photon OS 3.0 の参照 DNS サーバの設定は、

これまでの Photon OS とは様子が変わっているようです。

今回は、Photon OS 3.0 の DNS サーバ アドレスの確認と、設定変更をしてみます。

 

Photon OS 3.0 は、GitHub の URL からダウンロードできる

「OVA with virtual hardware v13 (UEFI Secure Boot)」を利用しています。

Downloading Photon OS · vmware/photon Wiki · GitHub

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

VMware Photon OS 3.0

PHOTON_BUILD_NUMBER=26156e2

 

Photon 3.0 の /etc/resolv.conf は下記のように、

nameserver に「127.0.0.53」というアドレスが設定されています。

root@photon-machine [ ~ ]# cat /etc/resolv.conf

# This file is managed by man:systemd-resolved(8). Do not edit.

#

# This is a dynamic resolv.conf file for connecting local clients to the

# internal DNS stub resolver of systemd-resolved. This file lists all

# configured search domains.

#

# Run "resolvectl status" to see details about the uplink DNS servers

# currently in use.

#

# Third party programs must not access this file directly, but only through the

# symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a different way,

# replace this symlink by a static file or a different symlink.

#

# See man:systemd-resolved.service(8) for details about the supported modes of

# operation for /etc/resolv.conf.

 

nameserver 127.0.0.53

 

このアドレスは、DNS サーバ関連のようで、UDP 53 番ポートで待ち受けているようです。

root@photon-machine [ ~ ]# ss -an | grep 127.0.0.53

udp   UNCONN  0        0                              127.0.0.53%lo:53                                               0.0.0.0:*

 

そして 53番ポートのプロセスを確認してみると、

resolv.conf のコメントとも関係ありそうな systemd-resolve というものです。

root@photon-machine [ ~ ]# tdnf install -y lsof

root@photon-machine [ ~ ]# lsof -i:53 -P -n

COMMAND   PID            USER   FD   TYPE DEVICE SIZE/OFF NODE NAME

systemd-r 205 systemd-resolve   12u  IPv4   3644      0t0  UDP 127.0.0.53:53

root@photon-machine [ ~ ]# ps -p 205

  PID TTY          TIME CMD

  205 ?        00:00:00 systemd-resolve

 

これは、systemd 229 以降に導入された名前解決マネージャーの仕組みのようです。

https://www.freedesktop.org/wiki/Software/systemd/resolved/

 

ちなみに、Photon 3.0 は systemd 239 でした。

root@photon-machine [ ~ ]# rpm -q systemd

systemd-239-10.ph3.x86_64

 

DNS サーバのアドレスは、/etc/systemd/network/*.network ファイルの

「DNS=」で設定したものが反映されます。

 

Photon OS 3.0 では、デフォルトでは DHCP 設定のファイルが配置されています。

root@photon-machine [ ~ ]# cat /etc/systemd/network/99-dhcp-en.network

[Match]

Name=e*

 

[Network]

DHCP=yes

IPv6AcceptRA=no

 

現時点では、DHCP 設定により自宅ラボの  DNS サーバ 2台が設定されています。

root@photon-machine [ ~ ]# resolvectl dns

Global:

Link 2 (eth0): 192.168.1.101 192.168.1.102

 

resolvectl では、より詳細な情報も確認できます。

(デフォルトだとページャが作用しますが、とりあえず cat で全体表示しています)

root@photon-machine [ ~ ]# resolvectl | cat

Global

       LLMNR setting: no

MulticastDNS setting: yes

  DNSOverTLS setting: no

      DNSSEC setting: no

    DNSSEC supported: no

Fallback DNS Servers: 8.8.8.8

                      8.8.4.4

                      2001:4860:4860::8888

                      2001:4860:4860::8844

          DNSSEC NTA: 10.in-addr.arpa

                      16.172.in-addr.arpa

                      168.192.in-addr.arpa

                      17.172.in-addr.arpa

                      18.172.in-addr.arpa

                      19.172.in-addr.arpa

                      20.172.in-addr.arpa

                      21.172.in-addr.arpa

                      22.172.in-addr.arpa

                      23.172.in-addr.arpa

                      24.172.in-addr.arpa

                      25.172.in-addr.arpa

                      26.172.in-addr.arpa

                      27.172.in-addr.arpa

                      28.172.in-addr.arpa

                      29.172.in-addr.arpa

                      30.172.in-addr.arpa

                      31.172.in-addr.arpa

                      corp

                      d.f.ip6.arpa

                      home

                      internal

                      intranet

                      lan

                      local

                      private

                      test

 

Link 2 (eth0)

      Current Scopes: DNS

       LLMNR setting: yes

MulticastDNS setting: no

  DNSOverTLS setting: no

      DNSSEC setting: no

    DNSSEC supported: no

  Current DNS Server: 192.168.1.101

         DNS Servers: 192.168.1.101

                      192.168.1.102

 

ためしに、DNS サーバのアドレスを変更してみます。

設定ファイルを vi エディタで編集します。

root@photon-machine [ ~ ]# vi /etc/systemd/network/99-dhcp-en.network

 

今回は、下記の赤字部分を追記します。

[Match]

Name=e*

 

[Network]

DHCP=yes

IPv6AcceptRA=no

Domains=go-lab.jp

DNS=192.168.1.1

DNS=192.168.1.2

 

ネットワークを再起動します。

root@photon-machine [ ~ ]# systemctl restart systemd-networkd

 

DNS サーバアドレスが追加登録されました。

DHCP サーバによる DNS サーバのアドレスよりも高優先度で

ファイルに追記した DNS サーバが追加されました。

root@photon-machine [ ~ ]# resolvectl dns

Global:

Link 2 (eth0): 192.168.1.1 192.168.1.2 192.168.1.101 192.168.1.102

 

resolvectl コマンドの末尾 10行だけ表示してみると、

「Domains」のドメインも追加されています。

root@photon-machine [ ~ ]# resolvectl | tail -n 10

       LLMNR setting: yes

MulticastDNS setting: no

  DNSOverTLS setting: no

      DNSSEC setting: no

    DNSSEC supported: no

         DNS Servers: 192.168.1.1

                      192.168.1.2

                      192.168.1.101

                      192.168.1.102

          DNS Domain: go-lab.jp

 

実際に名前解決が発生すると、利用されている DNS サーバ(Current DNS Server)がわかります。

root@photon-machine [ ~ ]# resolvectl | tail -n 10

MulticastDNS setting: no

  DNSOverTLS setting: no

      DNSSEC setting: no

    DNSSEC supported: no

  Current DNS Server: 192.168.1.1

         DNS Servers: 192.168.1.1

                      192.168.1.2

                      192.168.1.101

                      192.168.1.102

          DNS Domain: go-lab.jp

 

DNS サーバ のアドレスが変更されても、/etc/resolv.conf のアドレスは

127.0.0.53 のままですが、サーチドメインは追加されます。

root@photon-machine [ ~ ]# grep -v '#' /etc/resolv.conf

 

nameserver 127.0.0.53

search go-lab.jp

 

以上。Photon OS 3.0 の DNS サーバ アドレス設定の様子でした。

VMware Photon OS 3.0 で、簡易的な DNS サーバを構築してみます。

今回は、Photon OS の RPM リポジトリに登録されている dnsmasq を利用します。

 

Photon OS の準備。

VMware から提供されている、Photon OS の OVA をデプロイします。

今回は、「OVA with virtual hardware v13 (UEFI Secure Boot)」を利用しました。

Downloading Photon OS · vmware/photon Wiki · GitHub

 

OVA ファイルをデプロイ→パワーオンします。

そして、root / changeme で初期パスワードを変更してログインします。

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

VMware Photon OS 3.0

PHOTON_BUILD_NUMBER=26156e2

 

ホスト名を、わかりやすいもの(今回は lab-dns-01)に変更しておきます。

ログインしなおすと、bash のプロンプトにもホスト名が反映されます。

root@photon-machine [ ~ ]# hostnamectl set-hostname lab-dns-01

 

ネットワーク設定は、DHCP を利用しています。

 

DNS サーバの構築。(dnsmasq)

まず、dnsmasq をインストールします。

root@lab-dns-01 [ ~ ]# tdnf install -y dnsmasq

root@lab-dns-01 [ ~ ]# rpm -q dnsmasq

dnsmasq-2.79-2.ph3.x86_64

 

dnsmasq では、hosts ファイルのエントリを DNS レコードとして利用できます。

/etc/hosts ファイルに、DNS レコードの情報を記入します。

root@lab-dns-01 [ ~ ]# echo '192.168.1.20 base-esxi-01.go-lab.jp' >> /etc/hosts

root@lab-dns-01 [ ~ ]# echo '192.168.1.30 lab-vcsa-01.go-lab.jp' >> /etc/hosts

root@lab-dns-01 [ ~ ]# tail -n 2 /etc/hosts

192.168.1.20 base-esxi-01.go-lab.jp

192.168.1.30 lab-vcsa-01.go-lab.jp

 

dnsmasq を起動します。

root@lab-dns-01 [ ~ ]# systemctl start dnsmasq

root@lab-dns-01 [ ~ ]# systemctl is-active dnsmasq

active

root@lab-dns-01 [ ~ ]# systemctl enable dnsmasq

Created symlink /etc/systemd/system/multi-user.target.wants/dnsmasq.service → /lib/systemd/system/dnsmasq.service.

 

hosts ファイルを編集した場合は、dnsmasq サービスを再起動しておきます。

root@lab-dns-01 [ ~ ]# systemctl restart dnsmasq

 

iptables で、DNS のポートを開放しておきます。

iptables-save コマンドを利用するかわりに、/etc/systemd/scripts/ip4save ファイルへの

「-A INPUT -p udp -m udp --dport 53 -j ACCEPT」直接追記でも、同様に iptables の設定を永続化できます。

root@lab-dns-01 [ ~ ]# iptables -A INPUT -p udp -m udp --dport 53 -j ACCEPT

root@lab-dns-01 [ ~ ]# iptables-save > /etc/systemd/scripts/ip4save

root@lab-dns-01 [ ~ ]# systemctl restart iptables

 

名前解決の確認。

別の Photon OS 3.0 に、bindutils をインストールします。

root@photon-machine [ ~ ]# tdnf install -y bindutils

 

bindutils には、nslookup や dig コマンドが含まれます。

root@photon-machine [ ~ ]# rpm -ql bindutils

/etc/named.conf

/usr/bin/dig

/usr/bin/host

/usr/bin/nslookup

/usr/lib/tmpfiles.d/named.conf

/usr/share/man/man1/dig.1.gz

/usr/share/man/man1/host.1.gz

/usr/share/man/man1/nslookup.1.gz

 

登録したレコードの名前解決ができることを確認します。

ここでは、「lab-vcsa-01.go-lab.jp」と「192.168.1.30」を正引き / 逆引きで確認してみます。

「192.168.1.15」は、dnsmasq をインストールした DNS サーバのアドレスです。

root@photon-machine [ ~ ]# nslookup lab-vcsa-01.go-lab.jp 192.168.1.15

Server:         192.168.1.15

Address:        192.168.1.15#53

 

Name:   lab-vcsa-01.go-lab.jp

Address: 192.168.1.30

 

root@photon-machine [ ~ ]# nslookup 192.168.1.30 192.168.1.15

30.1.168.192.in-addr.arpa       name = lab-vcsa-01.go-lab.jp.

 

 

これで、ラボなどで利用する DNS サーバが用意できます。

 

以上、Photon OS 3.0 を DNS サーバにしてみる話でした。

自宅ラボの vSAN のキャッシュ ディスク容量について考える機会があり、

ためしに、vROps(vRealize Operations Manager)で、vSAN を見てみました。

今回は、vROps 7.5 で、vSAN 6.7 U1 を表示しています。

 

vROps では、vSAN アダプタを設定ずみです。

vrops-vsan-cache-size-00.png

 

vROps では vSAN のモニタリングも可能で、

よく話題になる、ディスク グループの書き込みバッファの空き容量(%)が確認できたりします。

vrops-vsan-cache-size-01.png

 

それでは、キャッシュ ディスクの推奨サイズを確認してみます。

「環境」→「すべてのオブジェクト」を開きます。

vrops-vsan-cache-size-02.png

 

「すべてのオブジェクト」→「vSAN アダプタ」→「キャッシュ ディスク」配下の

キャッシュ ディスクを選択します。

ESXi ホストに 128GB のキャッシュ用SSDが搭載されていることがわかります。

vrops-vsan-cache-size-03.png

 

キャッシュ ディスクを選択した状態で、

「すべてのメトリック」→「キャパシティ分析が生成されました」→「ディスク容量」

を開いて、「推奨サイズ(GB)」をダブルクリックすると、推奨サイズのグラフが表示されます。

この環境だと 59.62GB が推奨のようなので、キャッシュ ディスクの容量は十分なようです。

vrops-vsan-cache-size-04.png

 

ちなみにキャッシュ ディスクの情報は、下記のように「vSAN およびストレージ デバイス」

からでも表示できます。しかしキャッシュ ディスクだけを見る場合は、今回のように

「すべてのオブジェクト」からのツリーのほうが確認しやすいかなと思います。

vrops-vsan-cache-size-05.png

 

ちなみに、ドキュメントにも一応 vSAN のメトリックが記載されています。

(ただ、実機と一致はしていないような気も・・・)

vSAN のメトリック

 

まだ vROps をデプロイ&情報収集を開始してまもない状態の情報なので、

令和になったらまた見てみようと思います。

 

以上、vROps で vSAN キャッシュ ディスクの推奨サイズを見てみる話でした。

vSAN 6.7 U1 では、「仮想マシン ストレージ ポリシー」を考慮した

データストア空き容量の確認ができるようになっています。

 

下記のように、vSAN データストアの「容量の概要」画面の

「ポリシーで使用可能な容量」で仮想マシンが利用できる空き容量を確認できます。

スクリーンショットでは、デフォルトのポリシー「vSAN Default Storage Policy」で算出されています。

vsan-usage-01.png

 

そこで、別の仮想マシンストレージポリシーで使用可能容量を確認してみます。

デフォルトのポリシーでは「許容される障害の数:1 件の障害 - RAID-1(ミラーリング)」なので、

あえて、「policy-vsan-raid0」という名前で「データの冗長性なし」のポリシーを作成しました。

vsan-usage-02.png

 

「容量の概要」画面でこのポリシーを指定すると、このポリシーを利用した場合に

ポリシーで使用可能な容量が 2倍になることがわかります。(ただし冗長性はありません)

vsan-usage-03.png

 

実は、この情報は PowerCLI でも確認できるようになりました。

PowerCLI 11.2 Released, with more goodness for vSAN!

 

そこで、PowerCLI でも 同様の空き容量確認をしてみます。

 

今回は、PowerCLI 11.2 を利用しています。vCenter には既に接続ずみです。

PowerCLI> Import-Module VMware.PowerCLI

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

 

Name            Version

----            -------

VMware.PowerCLI 11.2.0.12483598

 

 

PowerCLI では、Get-VsanSpaceUsage で vSAN の容量情報を確認できます。

※ infra-cluster-01 は、vSAN クラスタの名前を指定しています。

 

ただし、下記にあるような FreeSpaceGB や CapacityGB には、

今回確認しているポリシーをもとにした空き容量が反映されません。

そこで、VsanWhatIfCapacity プロパティを確認します。

PowerCLI> Get-VsanSpaceUsage -Cluster infra-cluster-01

 

Cluster              FreeSpaceGB     CapacityGB

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

infra-cluster-01     2,911.358       4,657.552

 

 

特に仮想マシン ストレージ ポリシーを指定していない場合、

VsanWhatIfCapacity は情報を持ちません。

PowerCLI> Get-VsanSpaceUsage -Cluster infra-cluster-01 | select -ExpandProperty VsanWhatIfCapacity

PowerCLI>

 

デフォルトのポリシーを指定した場合です。

PowerCLI> Get-VsanSpaceUsage -Cluster infra-cluster-01 -StoragePolicy "vSAN Default Storage Policy" | select -ExpandProperty VsanWhatIfCapacity | Format-List

 

StoragePolicy         : vSAN Default Storage Policy

TotalWhatIfCapacityGB : 2328.77610206604

FreeWhatIfCapacityGB  : 1455.28823816683

 

 

今回作成した「policy-vsan-raid0」を指定すると、結果に反映されます。

PowerCLI> Get-VsanSpaceUsage -Cluster infra-cluster-01 -StoragePolicy "policy-vsan-raid0" | select -ExpandProperty VsanWhatIfCapacity | Format-List

 

StoragePolicy         : policy-vsan-raid0

TotalWhatIfCapacityGB : 4657.55220413208

FreeWhatIfCapacityGB  : 2910.5833046427

 

 

独自の仮想マシン ストレージ ポリシーを作成した時などに

確認手順に取り込んでおくと便利かもしれないと思いました。

 

以上、vSAN データストアの空き容量確認についての話でした。

vSAN に RAID5 / RAID6 の 仮想ディスク(VMDK)を配置するには、ノード数の要件があります。

  • RAID5 → 4ノード以上(4つ以上のフォルト ドメイン)
  • RAID6 → 6ノード以上(6つ以上のフォルト ドメイン)

参考: RAID 5 または RAID 6 イレージャ コーディングの使用

 

下記のサイトによると、これは vSAN の RAID の実装によるもので、

RAID5 が 4つ、RAID6 が 6つのコンポーネントとして実装されているためのようです。

 

VSAN ERASURE CODING FAILURE HANDLING

https://cormachogan.com/2018/12/13/vsan-erasure-coding-failure-handling/

 

そこで今回は 6より多いノード数で、

実際に vSAN の RAID5 / RAID6 ポリシーの VM を作成してみました。

 

vSAN 環境。

下記のように、オールフラッシュディスクグループの7ノード構成にしています。

  • vSAN 6.7 U1
  • ESXi 7ノード
  • オール フラッシュ(キャッシュ層 SSD + キャパシティ層 SSD)ディスクグループ
  • ディスクグループは各ノードで 1つずつ(キャッシュ層 x1 + キャパシティ層 x2)
  • フォールト ドメインはデフォルト構成のまま

vsan-raid56-00.png

 

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

RAID5 のストレージポリシーを作成します。

今回は「許容される障害の数」だけデフォルト値から変更しています。

vsan-raid56-01.png

 

RAID5 のポリシー名は「vSAN-RAID5-Policy」にしました。

vsan-raid56-02.png

 

RAID6のポリシーも、同様に「vSAN-RAID6-Policy」として作成しました。

vsan-raid56-04.png

 

仮想マシンの作成。(RAID5)

仮想マシンを、「vSAN-RAID5-Policy」で作成しました。

ちなみに、今回は 40GB で Thin プロビジョニングの VMDK を 1つだけ作成しています。

vsan-raid56-05.png

 

RAID5 になっている仮想ディスクの物理配置を確認すると、ノード数が4つより多くても、

コンポーネントは 4つ(4ノード)に分散されています。

vsan-raid56-06.png

 

仮想マシンの作成。(RAID6)

次に、仮想マシンを「vSAN-RAID6-Policy」で作成しました。

vsan-raid56-07.png

 

RAID6 の仮想ディスクの物理配置についても、

ノード数が4つより多くても、コンポーネントは 6つ(6ノード)に分散されています。

vsan-raid56-08.png

 

vSAN の RAID5 / RAID6 は、基本的にはノード数が多いからといって

RAID のストライプ数があわせて増加するわけではないようです。

おそらくは、可用性と性能のバランスをとった設計なのだろうと思います。

 

以上、vSAN の RAID5 / RAID6 の仮想ディスク コンポーネントを見てみる話でした。

vSphere 6.0 から vCenter 間での vMotion が可能になりましたが、

標準的な vSphere Web Client / vSphere Client(旧 HTML5 Client)から実行するには

vCenter が同一の PSC / vSphere Single Sign-On(SSO)ドメインに所属している必要があります。

そして vCenter の SSO ドメインが異なる場合の vCenter 間の vMotion は、

API や PowerCLI から実行する必要があります。

vCenter Server インスタンス間の移行の要件

 

そこで、今回は PowerCLI を利用して、できるだけシンプルな構成で

Cross vCenter vMotion を実行してみます。

 

今回の環境。

vCenter 6.7 を 2台用意しました。それぞれ別の SSO ドメインに所属しているので、

それぞれ別の vSphere Client からの管理となっています。

 

移行元の vCenter の名前は、lab-nsxt-vcsa-01.go-lab.jp です。

この vCenter 配下の VM「vm05」を vMotion します。

xvc-vmotion-01.png

 

移行先の vCenter の名前は、infra-vc-01.go-lab.jp です。

xvc-vmotion-02.png

 

PowerCLI 11 を利用します。

PowerCLI> Get-Module -ListAvailable VMware.PowerCLI | select Name,Version

 

Name            Version

----            -------

VMware.PowerCLI 11.0.0.10380590

 

 

PowerCLI による Cross vCenter vMotion の実行。

今回は、PowerCLI のスクリプト実行ではなく、対話的な実行(コマンドラインの手入力)で

できるだけ簡潔に Cross vCenter vMotion を実行してみます。

 

まず、vMotion 元 / 先それぞれの vCenter に接続します。

PowerCLI> $vc_a = Connect-VIServer lab-nsxt-vcsa-01.go-lab.jp

PowerCLI> $vc_b = Connect-VIServer infra-vc-01.go-lab.jp

 

今回は、vCenter のバージョンがそろっています。

PowerCLI> $vc_a | select Name,Version,Build

 

Name                       Version Build

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

lab-nsxt-vcsa-01.go-lab.jp 6.7.0   10244857

 

 

PowerCLI> $vc_b | select Name,Version,Build

 

Name                  Version Build

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

infra-vc-01.go-lab.jp 6.7.0   10244857

 

 

vMotion 先として指定するため、ESXi、データストア、ポートグループを取得して、

それぞれ1件ずつ取得できていることを確認しておきます。

確実に移行先 vCenter から取得するため「-Server」で vCenter を明示的に指定しています。

 

データストアを取得します。

PowerCLI> $ds = Get-Datastore -Server $vc_b -Name "vsanDatastore"

PowerCLI> $ds | select Name,Type

 

Name          Type

----          ----

vsanDatastore vsan

 

 

今回の宛先ポートグループは、vDS の分散仮想スイッチです。

PowerCLI> $pg = Get-VDPortgroup -Server $vc_b -Name "dvpg-infra-0000"

PowerCLI> $pg | select Name

 

Name

----

dvpg-infra-0000

 

 

宛先のESXi です。

ちなみに Cross vCenter vMotion の宛先(Move-VM の -Destination)には、

ESXi(VMHost)かリソースプールを指定できます。

PowerCLI> $hv = Get-VMHost -Server $vc_b -Name "infra-esxi-01.go-lab.jp"

PowerCLI> $hv | select Name

 

Name

----

infra-esxi-01.go-lab.jp

 

 

VM「vm05」の現在の配置を確認しておきます。

「-Server」では、移行元の vCenter を指定しています。

PowerCLI> Get-VM -Server $vc_a -Name vm05 | select Name,PowerState,VMHost,@{N="vCenter";E={$_.Uid -replace ".*@|:.*",""}}| fl

 

Name       : vm05

PowerState : PoweredOn

VMHost     : lab-esxi-21.go-lab.jp

vCenter    : lab-nsxt-vcsa-01.go-lab.jp

 

 

それでは vm05 を vMotion します。

オプションで、あらかじめ取得した ESXi、データストア、ポートグループを指定しています。

PowerCLI> Get-VM -Server $vc_a -Name vm05 | Move-VM -Destination $hv -Datastore $ds -PortGroup $pg

 

vMotion 完了後に VM の配置を確認すると、期待通り vCenter 間で移動されたことがわかります。

PowerCLI> Get-VM -Name vm05 | select Name,PowerState,VMHost,@{N="vCenter";E={$_.Uid -replace ".*@|:.*",""}} | fl

 

Name       : vm05

PowerState : PoweredOn

VMHost     : infra-esxi-01.go-lab.jp

vCenter    : infra-vc-01.go-lab.jp

 

 

今回の処理を vSphere Client から見た様子。

ちなみに vMotion タスクの進捗は、PowerCLI で実行した場合でも

vSphere Client から確認することができます。

 

vMotion 実行中の、移行元 vCenter です。

xvc-vmotion-04.png

 

ほぼ同じタイミングでの、移行先 vCenter です。

タスク ステータスの進捗%は、移行元 / 先で一致するわけではありません。

xvc-vmotion-05.png

 

vCenter をまたいで、指定したホストに vMotion されました。

xvc-vmotion-06.png

 

このように、仮想マシンの vNIC や VMDK の構成がシンプルであれば、

対話的に PowerCLI を利用したとしても(PowerCLI スクリプトを作りこむことをしなくても)

簡単に Cross vCenter vMotion できます。

 

またそれぞれの vCenter / ESXi では、従来の vMotion と同様に

vmkポートでの vMotion トラフィックの有効化や、通信経路でのポート解放などを

済ませておく必要があります。

 

以上、PowerCLI で Cross vCenter vMotion を実行してみる話でした。

近年の日本では、クリスマスのアドベントカレンダーに見立てて

12月に1日1回、ブログ投稿するイベントが流行しています。

そこで今年は、さまざまな ネステッド vSAN 6.7 U1 を構成してみました。

 

Nested vSAN Advent Calendar 2018

https://adventar.org/calendars/3712

 

今回のネステッド vSAN は、下記のように構築しています。

PowerCLI スクリプトなどを利用しています。

図解 ネステッド vSAN ラボ。

ネステッド vSAN ラボを構築するための工夫 Part.1。(物理 マシン ESXi ~ VCSA デプロイ)

ネステッド vSAN ラボを構築するための工夫 Part.2。(物理マシン ESXi と ESXi VM の準備)

ネステッド vSAN ラボを構築するための工夫 Part.3。(vSAN クラスタ構築)

ネステッド vSAN ラボを構築するための工夫 Part.4。(スクリプトでの簡素化)

 

 

各日の投稿です。

 

スタンダードな 4ノード、ハイブリッド構成。

ネステッド vSAN 6.7 U1 を楽しむ。2018-12-01

 

3ノード。

ネステッド vSAN 6.7 U1 を楽しむ。2018-12-02

 

vCenter 配下に、2つの vSAN。

ネステッド vSAN 6.7 U1 を楽しむ。2018-12-03

 

オールフラッシュ構成。

ネステッド vSAN 6.7 U1 を楽しむ。2018-12-04

 

複数のキャパシティ層ディスク。

ネステッド vSAN 6.7 U1 を楽しむ。2018-12-05

 

複数のキャパシティ層ディスク。(さらにディスクを増やす)

ネステッド vSAN 6.7 U1 を楽しむ。2018-12-06

 

複数のキャパシティ層ディスク。(構成の上限)

ネステッド vSAN 6.7 U1 を楽しむ。2018-12-07

 

キャパシティ層ディスクのサイズ調整。VSAN.ClomMaxComponentSizeGB

ネステッド vSAN 6.7 U1 を楽しむ。2018-12-08

 

RAID5。

ネステッド vSAN 6.7 U1 を楽しむ。2018-12-09

 

RAID6。

ネステッド vSAN 6.7 U1 を楽しむ。2018-12-10

 

2ノード。

ネステッド vSAN 6.7 U1 を楽しむ。2018-12-11

 

2ノードと WTS。

ネステッド vSAN 6.7 U1 を楽しむ。2018-12-12

 

2ノード → 3ノード。

ネステッド vSAN 6.7 U1 を楽しむ。2018-12-13

 

vSAN プロアクティブ テスト。

ネステッド vSAN 6.7 U1 を楽しむ。2018-12-14

 

ストレッチ クラスタでのネットワーク遅延テスト。

ネステッド vSAN 6.7 U1 を楽しむ。2018-12-15

 

vSAN とラック障害対策。

ネステッド vSAN 6.7 U1 を楽しむ。2018-12-16

 

vSAN と DC / サイト障害対策。

ネステッド vSAN 6.7 U1 を楽しむ。2018-12-17

 

ディスクグループがない vSAN ノード。

ネステッド vSAN 6.7 U1 を楽しむ。2018-12-18

 

重複排除・圧縮。

ネステッド vSAN 6.7 U1 を楽しむ。2018-12-19

 

vSAN iSCSI ターゲット。

ネステッド vSAN 6.7 U1 を楽しむ。2018-12-20

 

暗号化。

ネステッド vSAN 6.7 U1 を楽しむ。2018-12-21

 

1ノード。

ネステッド vSAN 6.7 U1 を楽しむ。2018-12-22

 

複数ディスクグループ構成。

ネステッド vSAN 6.7 U1 を楽しむ。2018-12-23

 

VCSA インストーラによる 1ノード vSAN。

ネステッド vSAN 6.7 U1 を楽しむ。2018-12-24

 

細かい手順までは触れていませんが、今月時点で最新バージョンの vSAN 6.7 U1 が

HTML5 Client(新 vSphere Client)で利用可能になった様子が俯瞰できるのではないかと思います。

 

以上、ネステッド vSAN を 1台の物理 PC で試してみる話でした。

今月は1日1回くらい、さまざまな ネステッド vSAN 6.7 U1 を構成してみています。

 

一連の投稿へのリンクは下記をどうぞ。

ネステッド vSAN 6.7 U1 を楽しむ。まとめ

 

昨日はこちら。

ネステッド vSAN 6.7 U1 を楽しむ。2018-12-23

 

24日目は、22日にも構成した 1ノードの vSAN です。

今回は、vCenter を vSAN 内部に配置しています。

構築の過程で、vCenter(VCSA)のデプロイと同時に配置先 vSAN を構成することで、

一時的に 1ノードの vSAN になるケースがあります。

 

vSAN-Cluster-20181224 クラスタ

  • ESXi は 1ノード
  • vCenter は vSAN 内部に配置

 

vCenter Server Appliance インストーラでの vSAN 構成。

vCenter Server を自身が管理する vSAN データストアに配置する場合に、

以前は、どこか一時的なデータストアに vCenter Server Appliance(VCSA)をデプロイして、

後から vSAN データストアに移動していました。

これは、vSAN の構成に vCenter が必要だったためです。

 

vSphere 6.7 では、VCSA のインストーラで仮想アプライアンスのデプロイと同時に

vSAN データストアを構成できるようになっています。

Deploying vSAN with vCenter Server Appliance

 

データストアの選択をする画面で、デプロイ先の ESXi に 1ノード vSAN クラスタを構成できます。

vsan-adv-d24-39.png

 

インストーラの画面遷移のなかで、vSAN データストアを構成するデバイスを指定できます。

このデプロイ先の ESXi は、今回は ネステッド ESXi です。

 

ちなみに、この環境の物理 ESXi には SSD が搭載されており、その上の VMDK による

「mpx.vmhba0:C0:T2:L0」(400GBの方)もフラッシュ デバイスとして認識されています。

このようなケースで、もし HDD として見せたい場合は、

ESXi の Host Client では HDD としてマーク付けができないようなので

ネステッド ESXi に SSH でログインして、esxcli コマンドで SATP ルールを設定します。

vsan-adv-d24-40.png

 

一連の VCSA のセットアップ処理が完了すると、

1ノード vSAN には、さらに構成(ノード追加や設定変更)が必要であると表示されます。

vsan-adv-d24-53.png

 

vCenter Server Appliance インストーラによる 1ノード vSAN。

インストーラで VCSA がデプロイされた直後の vSAN クラスタです。

  • デプロイした vCenter(VCSA): 192.168.1.39
    • 下スクリーンショットの vSphere Client は、この VCSAのもの。
  • VCSA が稼働する ESXi:  192.168.1.31

 

VCSA が稼働する ESXi ホストだけで、1ノード vSAN クラスタが構成されています。

相互通信する vSAN ノード(の ESXi ホスト)がいないため、

VMkernel ポートに「vSAN」トラフィックのタグが設定されていない状態でも vSAN として成り立っています。

そこでノード追加をする前に、このホストでも vSAN トラフィックのタグ設定が必要です。

vsan-adv-d24-02.png

 

VCSA の VM を見ると、vSAN データストア(vsanDatastore)に配置されていることがわかります。

しかし、仮想マシン ストレージ ポリシーは割り当てられていないようです。

この VM は、ノード追加後に、しかるべき仮想マシン ストレージ ポリシーを適用して

データの冗長性がある状態にする必要があります。

vsan-adv-d24-04.png

 

ただし、「vSAN Default Storage Policy」は作成されていて、

vsanDatastore にはデフォルトのポリシーとして設定されています。

vsan-adv-d24-06.png

 

ネスト環境での、VCSA インストーラによる 1ノード vSAN。

今回の ESXi ホストは、新規デプロイした vCenter(192.168.1.39)で管理されていますが、

それに対応する ESXi VM は、昨日までの vCenter(192.168.1.30)で管理されています。

 

ネスト環境で今回の構成を試す場合は、ネストの外側の物理 ESXi ではそれなりに高いスペックが要求されます。

VCSA のデプロイでは最低でも 10GB メモリが必要となるので、

デプロイ先の ネステッド ESXi でも、それを搭載できる容量が必要です。

今回は ESXi VM には 16GB のメモリを割り当てています。

 

ESXi VM(VCSA デプロイ先の ESXi にする)に割り当てる仮想ディスクも、

そこそこ大容量が必要で、まずシン プロビジョニングにすると思います。

VCSA のデプロイでは、ただテスト VM を作成するよりも容量を多めに消費するので

物理ホスト側のデータストア消費容量には要注意です。

(VCSA のデプロイ処理が途中で失敗すると特に悲しいため)

vsan-adv-d24-07.png

 

1ノード vSAN の動作確認をする場合、そもそも 1台は物理マシンがあるので、

2つ以上の物理ディスクが搭載されているのであれば、

あえてネステッド ESXi 上に構成する必要はありません。

それでもネスト環境を利用する場合は、下記のような事情がある場合かと思います。

  • 検証のために占有できる物理マシンがない。
  • 物理マシンに、搭載ディスク数がたりない。(キャッシュ層 / キャパシティ層むけ)

 

ただ個人的には、vSAN データストア上に vCenter を配置する場合には

VCSA インストーラを利用するよりも、一時的に vSAN 外部のデータストア

(ESXi をインストールするローカルディスクなど)にデプロイして、

複数ノード の vSAN を構成後に Storage vMotion で移動してしまうことが多いです。

 

まとめに、つづく。

ネステッド vSAN 6.7 U1 を楽しむ。まとめ

今月は1日1回くらい、さまざまな ネステッド vSAN 6.7 U1 を構成してみています。

 

一連の投稿へのリンクは下記をどうぞ。

ネステッド vSAN 6.7 U1 を楽しむ。まとめ

 

昨日はこちら。

ネステッド vSAN 6.7 U1 を楽しむ。2018-12-22

 

23日目は、ディスクグループが複数ある vSAN を構築してみました。

5日~6日目には、ディスク グループ内でのディスク数を増やしてみましたが、

今回は、それぞれの ESXi ホストに vSAN ディスク グループを 2つ作成してあります。

 

vSAN-Cluster-20181223 クラスタ

  • 3 ノード
  • ハイブリッド ディスク グループ x 2
    • 各ディスクグループで、キャッシュ層 SSD x 1、キャパシティ層 HDD x 2

 

複数ディスク グループ構成の vSAN。

複数の vSAN ディスク グループを作成した vSAN では、

それぞれのディスクグループに キャッシュ層 SSD と、キャパシティ層のデバイスが必要です。

キャッシュ層 / キャパシティ層のデバイスだけのディスク グループ は構成できません。

 

ESXi ホストのディスク グループの 1つです。

vsan-adv-d23-14.png

 

もうひとつのディスク グループのディスク構成です。

一般的に、ディスク構成(モデル、デバイス数、容量など)は、すべてのディスクグループで揃えます。

vsan-adv-d23-15.png

 

ホストあたりのディスク グループを複数にしても、

デフォルトの仮想マシン ストレージ ポリシー「vSAN Default Storage Policy」では

ホスト障害に耐えられるように、ホストをまたいでデータを配置します。

vsan-adv-d23-03.png

 

ちなみに、今回は単一の仮想 SCSI コントローラを使用したのですが、

障害リスクの分散を目的として複数のディスクグループを構成する場合は、

複数のディスク コントローラを搭載し、ディスクグループごとにコントローラを分けることもあります。

Designing and Sizing vSAN Hosts

 

それに近い構成にしたい場合、ネステッド vSAN 環境では

ネストの外側で、ESXi VM での仮想ディスク接続の設定を変更すれば、

複数の仮想 SCSI コントローラによる構成にすることも可能です。

 

もし、仮想 SCSI コントローラを追加するのであれば、

vSAN ディスク グループ作成の前に、ESXi VM は停止してから追加します。

vsan-adv-d23-17.png

 

そして ESXi VM の仮想ディスクごとに SCSI コントローラを指定します。

vsan-adv-d23-18.png

 

仮想マシン ストレージ ポリシーでストライプ数を増やしてみる。

複数のディスク グループがあるので、仮想マシン ストレージ ポリシーを調整して、

vSAN オブジェクトのコンポーネントを、それぞれの vSAN ディスクグループに配置してみます。

 

今回は、データの可用性はそのままで、ディスクのストライプ数だけを変更してみます。

このようなポリシーは、オブジェクトあたりのキャパシティ層ディスクが増加するため、

ハイブリッド ディスクグループでの I/O 性能向上を見込んで構成することもできます。

ただし、ネスト環境では性能面でのメリットはうけられません。

About vSAN Policies

 

ポリシーでのディスク ストライプ数の設定は、

「vSAN」→「詳細なポリシー ルール」→「オブジェクトあたりのディスク ストライプの数」

で設定することができます。

vsan-adv-d23-05.png

 

「vSAN-Stripe2-Policy」という名前で、ストライプ数が「2」のポリシーを作成します。

vsan-adv-d23-06.png

 

作成したポリシーを VM に適用して、コンプライアンスが「準拠」の状態にします。

vsan-adv-d23-16.png

 

VM のデータは元の RAID 1 だけの配置から、

コンポーネントを RAID 0 で分散したうえで RAID 1 を構成する配置に変更されました。

vsan-adv-d23-09.png

 

画面を横にスクロールすると、RAID 0 のコンポーネントが

それぞれ別の物理ディスクに配置されていることがわかります。

なお、今回は ホスト内のディスクで RAID 0 配置となりましたが、

vSAN では RAID 0 になったデータは、別のホストに分散配置されることもあります。

vsan-adv-d23-10.png

 

vSAN のデータ配置について実機確認するときには

最小ディスク構成の環境より、ディスク数が多い環境のほうが理解をしやすいかなと思います。

ディスク グループ構成を検討する場合も、ネステッド vSAN で同等のディスク数 / 容量の

vSAN ディスク グループの環境を作成してみると、なにか新たな気づきが得られるかもしれません。

 

つづく。

ネステッド vSAN 6.7 U1 を楽しむ。2018-12-24

今月は1日1回くらい、さまざまな ネステッド vSAN 6.7 U1 を構成してみています。

 

一連の投稿へのリンクは下記をどうぞ。

ネステッド vSAN 6.7 U1 を楽しむ。まとめ

 

昨日はこちら。

ネステッド vSAN 6.7 U1 を楽しむ。2018-12-21

 

22日目は、1ノードの vSAN です。

 

vSAN-Cluster-20181222 クラスタ

  • ESXi は 1ノード
  • vCenter は vSAN 外部に配置
  • 仮想マシン ストレージ ポリシーを 1ノード vSAN むけに調整。
    • デフォルト ポリシー自体は変更せず、VM ごとに適用。

 

実情として 1ノード vSAN は、vCenter を vSAN 上に配置する過程として一時的に

構成されることが多いかなと思います。

Deploying vSAN with vCenter Server Appliance

 

しかしリソースの都合上、今回も vCenter を vSAN 外部に配置しています。vSAN の外に配置しています。

 

1 ノード vSAN の様子。

1 ノード vSAN を構成すると、ノード障害に耐えられない構成なので、

vSAN の健全性テストで下記のようなエラーが検知されます。

vsan-adv-d22-04.png

 

仮想マシン ストレージ ポリシーも、デフォルトの「vSAN Default Storage Policy」では、

冗長性を満たせず(フォールト ドメインが足りず)、VM を作成することができません。

vsan-adv-d22-05.png

 

VM を作成しようとしても、デフォルトの仮想マシン ストレージ ポリシーのままでは、

vSAN データストアはポリシーに一致しません。

vsan-adv-d22-06.png

 

このまま vSAN データストアに VM を作成しようとしても・・・

vsan-adv-d22-07.png

 

フォールト ドメインが足りないためファイルが作成できず、VM の作成もエラーになります。

vsan-adv-d22-09.png

 

仮想マシン ストレージ ポリシーと 1 ノード vSAN の関係。

1 ノード vSAN のままの状態で VM を作成する場合は、

仮想マシン ストレージ ポリシーで工夫が必要で、ポリシーで

「強制プロビジョニング」を有効にするか、「データの冗長性なし」にします。

 

「強制プロビジョニング」を有効にすると、

ポリシーに一致しない状態でも、仮想ディスク を作成することができます。

 

「vSAN Default Storage Policy」をクローンして、

強制プロビジョニングを有効にしたポリシーを作成してみます。

vsan-adv-d22-10.png

 

強制プロビジョニングは、「vSAN」→「詳細なポリシー ルール」で設定できます。

vsan-adv-d22-12.png

 

「vSAN-SingleNode-Temp-Policy」という名前でポリシーを作成しました。

vsan-adv-d22-13.png

 

強制プロビジョニングのポリシーであれば、

新規 VM を作成するときに、vSAN データストアの互換性チェックは成功します。

vsan-adv-d22-14.png

 

VM の作成、起動はできますが、当然ながらポリシーの可用性は満たしていないので

コンプライアンス チェックではエラーになります。

vsan-adv-d22-16.png

 

一方「データの冗長性なし」は、ポリシーの「可用性」→「許容される障害の数」で設定できます。

vsan-adv-d22-17.png

 

「vSAN-SingleNode-Policy」という名前で

データの冗長性なしで、強制プロビジョニングは無効にしてあるポリシーを作成しました。

vsan-adv-d22-19.png

 

今度は、そもそもノード障害に耐えられなくてもよいポリシーを適用しているので、

ポリシーを割り当てた VM のコンプライアンス チェックは「準拠」になります。

vsan-adv-d22-21.png

 

しかし当然ながら、どちらのポリシーもデータの可用性があるわけではなく、

この VM の vSAN オブジェクトは、コンポーネントはそれぞれ 1つだけ作成されています。

この状態から冗長性(耐障害性)のある状態にするためには、

ノードを追加した後で、しかるべきポリシーを適用するとデータが複製されます。

vsan-adv-d22-22.png

 

本番環境で 1ノード vSAN がそのまま利用されることはないかなと思います。

しかし、構築の過程で、1ノードだけ先行構築して VM を作成したい場合や、

検証環境などでデータの冗長性より容量効率を重視するような場合は、

今回のようなポリシーを利用することもできます。

 

また構築の過程で、可用性の低いポリシーを適用する場合は、

ちゃんとしたポリシーに戻すことを忘れないよう、要注意です。

うっかりそのままにしても影響が少ないよう、

今回はデータストアのデフォルトポリシーは変更せず、VM 単位でのポリシー変更にしてみました。

 

つづく。

ネステッド vSAN 6.7 U1 を楽しむ。2018-12-23

今月は1日1回くらい、さまざまな ネステッド vSAN 6.7 U1 を構成してみています。

 

一連の投稿へのリンクは下記をどうぞ。

ネステッド vSAN 6.7 U1 を楽しむ。まとめ

 

昨日はこちら。

ネステッド vSAN 6.7 U1 を楽しむ。2018-12-20

 

21日目は、vSAN データストアの暗号化です。

 

vSAN-Cluster-20181221 クラスタ

  • ESXi は 3ノード
  • ハイブリッド ディスクグループ(データストアを暗号化
    • 鍵管理サーバ(KMS)を vSAN データストア外に配置。
  • vCenter は vSAN 外部に配置

 

暗号化された vSAN データストアの様子。

ディスクのデータ暗号化をするソリューションでは、一般的に、鍵管理サーバ(KMS)を必要とします。

Using Encryption on a vSAN Cluster

 

KMS は暗号化対象の外に配置する必要があるため、

今回はネスト外側の、物理 ESXi ホストの VM で KMS サービスを起動しています。

 

KMS は、自宅ラボ系の暗号化動作確認で頻繁に利用される、

William Lam さんが用意している OpenKMS の Docker コンテナを利用しています。

https://www.virtuallyghetto.com/2016/12/kmip-server-docker-container-for-evaluating-vm-encryption-in-vsphere-6-5.html

 

ちなみに、

今年の(日本の)vExperts Advent Calendar 2018 でも 12/4 の投稿で紹介されています。

https://adventar.org/calendars/3101#list-2018-12-04

 

 

vSAN クラスタで、暗号化が有効になっています。

vSAN での暗号化は、データストア全体に作用します。(vSAN オブジェクト単位ではなく)

vsan-adv-d21-01.png

 

vSAN の暗号化を有効化する前に、vCenter に鍵管理サーバ(KMS)を登録しておきます。

vsan-adv-d21-02.png

 

KMS は、必ず vSAN データストアの外部に配置します。

vsan-adv-d21-03.png

 

vSAN の健全性確認では、KMS との接続性の確認ができます。

vCenter と KMS のステータスです。

vsan-adv-d21-04.png

 

ESXi と KMS のステータスです。

vsan-adv-d21-05.png

 

KMS を停止した場合の影響を見てみる。

KMS の疑似障害として、KMS のサービスを起動している VM の vNIC を切断してみます。

vsan-adv-d21-06.png

 

KMS への接続はできなくなりますが、vSAN 上では VM が起動したままです。

vsan-adv-d21-07.png

 

メンテナンスモードにして、ESXi を再起動してみます。

まず、メンテナンスモードにします。

vsan-adv-d21-08.png

 

そして、ESXi をシャットダウンします。

vsan-adv-d21-09.png

 

ESXi が起動時に KMS にアクセスできない状態だと、

そのホストでは暗号化が有効化できなくなってしまいます。

vsan-adv-d21-10.png

 

この ESXi は暗号化モードになれず、ディスクへのアクセスが不可になっています。

vsan-adv-d21-14.png

 

vSAN 上の VM のデータ(vSAN オブジェクト)も、

ESXi ホスト 1台がローカル ディスクにアクセスできないため、可用性が低下した状態です。

まだ再起動していない ESXi が十分な台数あるため、VM のデータにはアクセス可能な状態です。

vsan-adv-d21-13.png

 

しかし、まだ暗号化が有効なホストが十分数のこっているため、

vSAN オブジェクトへのアクセスはできます。

そのためディスク暗号化が有効化できなくなった ESXi ホストでも、VM を起動させることは可能です。

ただし、この ESXi のローカル ディスクにアクセスできるようにするためには、

KMS を復旧する必要があります。

vsan-adv-d21-15.png

 

ちなみに、KMS と vCenter / ESXi の接続ができない場合は、vSAN の健全性チェックでも検知されます。

 

vCenter と KMS のステータスです。

vsan-adv-d21-11.png

 

ESXi と KMS のステータスです。

vsan-adv-d21-12.png

 

ネスト環境での vSAN データストア暗号化については、パフォーマンス検証には利用できませんが、

今回のように KMS やホスト障害などにかかわる挙動確認で有用かなと思います。

 

つづく。

ネステッド vSAN 6.7 U1 を楽しむ。2018-12-22

今月は1日1回くらい、さまざまな ネステッド vSAN 6.7 U1 を構成してみています。

 

一連の投稿へのリンクは下記をどうぞ。

ネステッド vSAN 6.7 U1 を楽しむ。まとめ

 

昨日はこちら。

ネステッド vSAN 6.7 U1 を楽しむ。2018-12-19

 

20日目は、vSAN の iSCSI ターゲット サービスを有効にして Linux サーバから接続してみます。

 

vSAN-Cluster-20181220 クラスタ

  • ESXi は 4ノード
  • ハイブリッド ディスクグループ
  • iSCSI ターゲット サービスを有効化。

 

iSCSI ターゲット サービスは、vSAN クラスタ単位で有効にします。

Using the vSAN iSCSI Target Service

 

vSAN クラスタでの iSCSI ターゲット / LUN の様子。

vSAN クラスタで、iSCSI ターゲット サービスが有効になっています。

本番利用であれば VMkernel ポート を iSCSI むけに追加すると思いますが、

今回は管理ネットワークの vmk0 を共用しています。

vsan-adv-d20-01.png

 

iSCSI ターゲットによる LUN は、vSAN データストア外部の物理マシンからの利用が想定されています。

(vSAN 上にある VM のゲスト OS がもつ iSCSI イニシエータからでも接続は可能です)

 

今回のネスト環境では、LUN を利用する Linux VM をネストの外側の物理 ESXi で稼働させ、

物理マシンからの iSCSI 接続に似せたネットワーク経路にしています。

 

今回の iSCSI クライアントになる VM「vm01-ext」の IP アドレスは「192.168.1.151」にしました。

ターゲットに接続する iSCSI イニシエータは、このアドレスです。

vsan-adv-d20-04.png

 

下記のようなターゲット / LUN を構成しました。

  • LUN として 10GB のディスクを 1つ作成しています。
  • 接続許可する iSCSI イニシエータを制限しています。

vsan-adv-d20-02.png

 

iSCSI の LUN も、vSAN の仮想ディスク オブジェクトとして作成されます。

vsan-adv-d20-05.png

 

そしてコンポーネントも、仮想マシン ストレージポリシーにしたがって VM の仮想ディスクと同様に分散されます。

vsan-adv-d20-06.png

 

iSCSI イニシエータ側(クライアントとなる Linux OS)の様子。

今回は、Oracle Linux から iSCSI 接続しています。

vSAN の iSCSI ターゲットに登録していたイニシエータ iqn がこのサーバに設定されています。

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

Oracle Linux Server release 7.5

[root@vm01-ext ~]# cat /etc/iscsi/initiatorname.iscsi

InitiatorName=iqn.1988-12.com.oracle:vm01-ext

 

Linux(192.168.1.151)から、vSAN ノードの 1台(192.168.1.32)に iSCSI で接続しています。

[root@vm01-ext ~]# netstat -na | grep :3260

tcp        0      0 192.168.1.151:60596     192.168.1.32:3260       ESTABLISHED

[root@vm01-ext ~]# ls -l /dev/disk/by-path/*iscsi*

lrwxrwxrwx. 1 root root 9 12月 20 23:40 /dev/disk/by-path/ip-192.168.1.32:3260-iscsi-iqn.1998-01.com.vmware.5271c93bf9783708-3aeec78f1c34de4e-lun-0 -> ../../sdb

 

接続先ノードが「192.168.1.32」になっているのは、

イニシエータ側での iSCSI 接続コマンド実行時にアドレスを指定したためです。

[root@vm01-ext ~]# iscsiadm -m discovery -t sendtargets -p 192.168.1.32

[root@vm01-ext ~]# iscsiadm -m node -p 192.168.1.32 --login

 

iSCSI LUN によるデバイスである /dev/sdb は、

「VMware   Virtual SAN」によるものだとわかります。

[root@vm01-ext ~]# lsscsi

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

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

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

 

このデバイスは、iSCSI Target で作成したとおり 10GB です。

[root@vm01-ext ~]# lsblk /dev/sdb

NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT

sdb    8:16   0  10G  0 disk

 

今回はシングル パスでの接続ですが、

マルチパスで複数の vSAN ノードに接続することもできます。

その場合は Linux 側でもマルチパス ドライバ(dm-multipath)などを利用することになるはずです。

 

つづく。

ネステッド vSAN 6.7 U1 を楽しむ。2018-12-21

今月は1日1回くらい、さまざまな ネステッド vSAN 6.7 U1 を構成してみています。

 

一連の投稿へのリンクは下記をどうぞ。

ネステッド vSAN 6.7 U1 を楽しむ。まとめ

 

昨日はこちら。

ネステッド vSAN 6.7 U1 を楽しむ。2018-12-18

 

19日目は、vSAN データストアで、重複排除・圧縮を有効にしています。

 

vSAN-Cluster-20181219 クラスタ

  • ESXi は 4ノード
  • オールフラッシュ ディスクグループ
  • ディスクグループは各ノードで 1つずつ
  • 重複排除(デデュープ)および圧縮あり

 

vSAN の重複排除と圧縮機能は、両方あわせて有効化することになります。

また、ハイブリッドではなくオールフラッシュのディスクグループが必要です。

Using Deduplication and Compression

 

vSAN クラスタで「デデュープおよび圧縮」が有効になっています。

vsan-adv-d19-01.png

 

重複排除・圧縮の要件により、

このクラスタの ESXi はオールフラッシュの vSAN ディスクグループにしています。

vsan-adv-d19-02.png

 

クラスタ容量では、デデュープおよび重複排除の容量も確認できるようになっています。

vsan-adv-d19-04.png

 

重複排除・圧縮が動作するか、VM をクローンしてみます。

vSAN データストアには、VM を 1台だけ配置しています。

この VM の容量は 3.14 GB です。

vsan-adv-d19-05.png

 

VM をクローンしてみます。

今回は、PowerCLI で VM を30台クローンしています。

このクラスタでは DRS を有効にしているので、クローン先に

ESXi ではなくクラスタ(リソースプール)を指定し、VM 配置を自動化しています。

PowerCLI> 1..30 | %{New-VM -VM "vm-template" -Name ("vm-" + $_.toString("00")) -ResourcePool "vSAN-Cluster-20181219" -Datastore "vsanDatastore"}

 

コマンドラインでは、下記のような指定をしています。

  • クローン元 VM は「vm-template」
  • クローン作成する VM の名前は「vm-<数字2桁>」。数字は 1~30
  • クローン先リソースプール(クラスタ)は「vSAN-Cluster-20181219」
  • クローン先のデータストアは「vsanDatastore」

vsan-adv-d19-06.png

 

データストアの容量が削減されている様子がわかります。

vsan-adv-d19-08.png

 

容量確認するときは、念のため、

データストアで「キャパシティ情報の更新」をしておくことをおすすめします。

(もしくは容量グラフ下の「更新」ボタンをクリック)

vsan-adv-d19-07.png

 

また、ネストの外側の物理マシン ESXi のデータストア空き容量にも、注意が必要です。

vsan-adv-d19-09.png

 

ネスト環境は一般的に、ラボやデモ用途で利用されるため、

ESXi VM の仮想ディスクをシン プロビジョニングで作成することが多いはずです。

そうすると、今回のように大量の VM クローンによってネストの外側の物理マシンで

データストア容量があふれてしまうことがあります。

(シック プロビジョニングの場合よりも、という意味あいにて)

 

今回のケースはそうならないようにしましたが、

データストアの空き容量がなくなって、シン プロビジョニングの VMDK 拡張できなくなると、

その時点で、VMDK 拡張しようとしていた VM は停止してしまいます。

vCenter の VM など、重要な VM が停止してしまうと致命的なので、このような検証をするときは、

  • ちゃんとデータストア容量に注意しておく。
  • 重要な VM をシック プロビジョニングで容量確保する。
  • あらかじめ重要な VM を別の NFS データストアなどに配置しておく。

といった工夫をするとよいかなと思います。

 

つづく。

ネステッド vSAN 6.7 U1 を楽しむ。2018-12-20

今月は1日1回くらい、さまざまな ネステッド vSAN 6.7 U1 を構成してみています。

 

一連の投稿へのリンクは下記をどうぞ。

ネステッド vSAN 6.7 U1 を楽しむ。まとめ

 

昨日はこちら。

ネステッド vSAN 6.7 U1 を楽しむ。2018-12-17

 

18日目は、ディスクグループが不均等な vSAN を構築してみました。

 

vSAN-Cluster-20181218 クラスタ

  • ESXi は 5ノード
  • ハイブリッド(SSD + HDD)ディスクグループ
  • ディスクグループは各ノードで 1つずつ
  • ただし、ディスクグループをもたない ESXi ホストあり

 

そもそも vSAN では、VM と仮想ディスクのデータ配置が

一致するとは限らない(データのローカリティ 意識しない)アーキテクチャです。

そのため機能的には、vSAN クラスタに、vSAN ディスクグループをもたない

ESXi ホストを配置することもできてしまいます。

ネスト環境であればホストのディスク構成を変更(追加 / 削除 / 容量変更)しやすいので、

試しに構成してみました。

 

今回は 5ノードの vSAN です。

VM「vm01」が、5台目のホスト「192.168.1.35」で起動しています。

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

vsan-adv-d18-02.png

 

vm01 の vSAN オブジェクトのデータの「物理ディスクの配置」を見ると、

192.168.1.31 ~ 192.168.1.33 のディスクグループに、コンポーネントが配置されています。

vsan-adv-d18-03.png

 

ESXi それぞれのディスクグループ構成を見ると、

192.168.1.31 ~ 192.168.1.33 以外の ESXi ホストは、ディスクグループが作成されていません。

vm01 が起動している ESXi「192.168.1.35」も、ディスクグループが作成されていないホストです。

vsan-adv-d18-04.png

 

もともと、NFS や iSCSI でのデータストアでもネットワーク経由のストレージを利用していて、

物理マシンの更改途中や、ディスク障害時にも、ディスクグループがなかったり、

ディスクグループの構成が不均等の ESXi ホストは存在することになります。

ディスクグループがないホストがある構成は、ESXi としては不思議な構成ではないかもしれません。

 

ただし、vSAN はホストの構成が統一された状態で最適に動作します。

Design Considerations for a vSAN Cluster

 

定常運用中の vSAN で ESXi ごとのディスクグループ構成が異なると、

ストレージ性能が不均等になりやすかったり、障害時の挙動が予測しにくくなったりと、

vSAN の特徴が活かせない構成となってしまいます。

 

そのため、本番運用する vSAN では、すべてのホストでディスク構成を揃えておき、

ディスクグループが不均等になる構成にするのは、セットアップ / ノード追加の途中や

ラボ用途のみとしておいたほうがよいかなと思います。

 

つづく。

ネステッド vSAN 6.7 U1 を楽しむ。2018-12-19

今月は1日1回くらい、さまざまな ネステッド vSAN 6.7 U1 を構成してみています。

 

一連の投稿へのリンクは下記をどうぞ。

ネステッド vSAN 6.7 U1 を楽しむ。まとめ

 

昨日はこちら。

ネステッド vSAN 6.7 U1 を楽しむ。2018-12-16

17日目は、vSAN ストレッチ クラスタを構成してみます。

 

今回は、vSAN のフォールト ドメインを利用して、

サイト(物理的なデータセンタなど)の障害対策を意識した構成をしてみます。

 

vSAN-Cluster-20181217 クラスタ

  • ESXi 6ノード
  • フォールト ドメインは 2つ作成 → それぞれ ESXi を 3ノードずつ配置
  • vCenter は vSAN 外部に配置
  • ストレッチ クラスタ(監視ホストは vSAN とは別のサイトに配置)

 

ストレッチ クラスタの vSAN 構成例。

以前に作成した 2ノード vSAN も、ストレッチ クラスタでしたが、

今回は、災害などでデータセンタ単位での障害が発生したケースを想定して、

1つの vSAN のうち部分的に別の DC などに配置するケースを想定しています。

ただし、実際に物理データセンタを用意するわけではなくネスト環境です。

 

ESXi ホストと VM を、どのデータセンタで起動させるか決めておきます。

データセンタごとに、ネットワークをわけています。

  • データセンタ A: ESXi は 192.168.10.31~33、vm01 が起動。
  • データセンタ B: ESXi は 192.168.20.34~36、vm02 が起動。

 

データセンタごとに、フォールト ドメインを作成しています。

vSAN クラスタは 1つですが、ESXi の物理配置は 2か所になります。

vsan-adv-d17-01.png

 

VM の配置調整のため、DRS を有効にしておきます。

vsan-adv-d17-02.png

 

DRS のアフィニティ ルールを作成しておきます。

データセンタ A むけのルールです。

vsan-adv-d17-05.png

 

データセンタ B むけのルールです。

vsan-adv-d17-06.png

 

VM 配置は、それぞれの VM が、想定した DC(の ESXi)です。

vsan-adv-d17-07.png

 

VM の vSAN オブジェクトのデータも、意図したとおりに分散配置されています。

vsan-adv-d17-04.png

 

vSphere HA も有効にしておきます。

vsan-adv-d17-03.png

 

データセンタ障害時のイメージ。

 

データセンタ A の障害をイメージして、ESXi ホスト 3台を同時に停止してみます。

今回も、ネストの外側から ESXi VM をパワーオフします。

VM の IP アドレスを見ると ESXi と ESXi VM の対応がわかり、

ESXi 192.168.10.31~33 は、ESXi VM の vm-esxi-01 ~ 03 にあたります。

vsan-adv-d17-09.png

 

vSphere HA で、データセンタ A にあった vm01 が再起動されました。

vsan-adv-d17-10.png

 

vm01 は、データセンタ B のホストで起動しています。

vsan-adv-d17-11.png

 

vm01 の、データセンタ A のフォールト ドメインに配置されたコンポーネントは、

意図したとおり障害になっています。

vsan-adv-d17-12.png

 

データセンタ A 全体の障害でも、フォールト ドメインにより

データの可用性が担保されて VM が起動することができています。

 

つづく。

ネステッド vSAN 6.7 U1 を楽しむ。2018-12-18