Skip navigation
1 2 3 Previous Next

にほんごVMware

358 posts

今月は1日1回くらい、さまざまな ネステッド 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 の特徴が活かせない構成となってしまいます。

 

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

ディスクグループが不均等になる構成にするのは、

vSAN のセットアップの途中、ノード追加の途中や

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

 

つづく。

今月は1日1回くらい、さまざまな ネステッド 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.1.31~33、vm01 が起動。
  • データセンタ B: ESXi は 192.168.1.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 がわかります。

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 が起動することができています。

 

つづく。

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

 

昨日はこちら。

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

 

16日目は、vSAN でフォールト ドメインを構成してみます。

フォールト ドメインは、2ノード vSAN / ストレッチ クラスタ でも構成したものです。

今回は、ストレッチクラスタではない vSAN でのフォールト ドメインで、

サーバ ラック障害対策を意識した構成をしてみます。

 

vSAN-Cluster-20181216 クラスタ

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

 

フォールト ドメインを利用した vSAN 構成例

今回は ESXi ホスト 6台を、3 つのサーバラックに 2台ずつ配置する想定とします。

ただし、実際に物理サーバ ラックがあるわけではなく、ネスト環境で構築します。

 

あわせて VM も、平常時に、どのサーバ ラックで起動させるか決めておきます。

  • サーバ ラック A: ESXi は 192.168.1.31~32、vm01 が起動。
  • サーバ ラック B: ESXi は 192.168.1.33~34、vm02 が起動。
  • サーバ ラック C: ESXi は 192.168.1.35~36、vm03 が起動。

 

6 ノードの vSAN で、フォールト ドメインを 3つ作成しています。

フォールト ドメインの名前は、対応する サーバ ラックがわかりやすいようにしました。

vsan-adv-d16-01.png

 

この vSAN クラスタでは、DRS を有効にしています。

DRS は、アフィニティ ルールを利用して

VM の配置(優先的に起動するサーバ ラック)を調整するために有効化しています。

vsan-adv-d16-04.png

 

DRS のアフィニティ ルールで利用するため、

サーバ ラックごとに、ESXi の「ホスト グループ」を作成しました。

vsan-adv-d16-08.png

 

サーバ ラックごとに「仮想マシン グループ」も作成しました。

vsan-adv-d16-09.png

 

サーバ ラック A むけの「ホスト グループ」と「仮想マシン グループ」は、

下記のように、「仮想マシン / ホスト ルール」でひもづけます。

サーバ ラック A のホスト(192.168.1.31、192.168.1.32)で

vm01 が優先的に起動するように、ルールのタイプを「仮想マシンをホスト上で実行」にしています。

これを「グループ内のホストで実行する必要があります」としないのは、

障害時の vSphere HA で、別ラックでも VM を起動したいためです。

vsan-adv-d16-10.png

 

同様に、サーバラック B むけのアフィニティ ルールも作成しています。

vsan-adv-d16-11.png

 

そして、サーバラック C むけのアフィニティ ルールです。

vsan-adv-d16-012.png

 

また、この vSAN クラスタでは、vSphere HA も有効にしています。

データストア障害(APD)時も、vSphere HA によって VM が自動起動がされるようにしています。

vsan-adv-d16-03.png

 

この vSAN クラスタで VM を起動すると、

それぞれ DRS アフィニティ ルールに従った配置になっています。

vsan-adv-d16-02.png

 

ラック障害時のイメージ

サーバ ラック A の障害をイメージして、ESXi ホスト 2台を同時に停止してみます。

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

 

今回の「仮想マシン ストレージ ポリシー」は、vSAN 6.7 U1 デフォルトの

ポリシー「vSAN Default Storage Policy」のままです。

そのため、データの可用性が保証されるのは、

フォールト ドメイン構成なしのままの場合は、VM が

vSphere HA で起動できないこともありえます。

 

今回はフォールト ドメインを構成しているので、

2台同時に ESXi をパワーオフしてみます。

vsan-adv-d16-13.png

 

ホスト 2台で障害が発生し、

vm01 が vSphere HA で再起動されたことがわかります。

この VM は、アフィニティ ルール設定外のホストでも

vSAN 上のデータにアクセスして起動できています。

vsan-adv-d16-14.png

 

あらためて、物理的なデータ配置を確認すると、

vm01 の vSAN オブジェクトは、いずれもフォールト ドメインを

またいでデータ配置されています。

vsan-adv-d16-15.png

 

このように、フォールト ドメインの構成みにより

サーバ ラック A 全体の障害でも(ESXi が 2ノード同時に停止しても)

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

 

つづく。

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

 

昨日はこちら。

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

 

15日目は、2ノード vSAN を 2セット展開しています。

監視ホストを、疑似的に、vSAN から物理的に距離があるデータセンタに配置してみます。

  • vSAN-Cluster-20181215 クラスタ: 2 ノード vSAN
  • 監視ホストの vSAN Witness Appliance は、離れたデータセンタに配置
    • 2ノード vSAN の Witness と、監視ホストの vSAN ネットワークは別セグメント。
    • 監視ホストへのトラフィックは、ネットワーク遅延あり。

 

2ノード vSAN の ESXi ホストと、監視ホストを別ネットワークに配置しています。

  • vCenter と vSAN の ESXi: 192.168.1.0/24 ネットワーク
  • 監視ホスト: 192.168.10.0/24 ネットワーク

vsan-adv-d15-01.png

 

この2つのネットワークは、拠点間接続ルータ役の Linux VM で疑似的に構成しています。

vsan-adv-d15-08.png

 

拠点間接続ルータ役の Linux。

今回利用した Linux は、Oracle Linux 7.5 です。

ホスト名は、VM 名にあわせて「lab-gw-01」にしています。

[root@lab-gw-01 ~]# cat /etc/oracle-release

Oracle Linux Server release 7.5

 

vNIC を 2つ用意して、それぞれのセグメントの IP アドレスを付与しておきます。

 

vSAN ネットワーク側 vNIC のネットワーク設定。

[root@lab-gw-01 ~]# ip address show ens192

2: ens192: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000

    link/ether 00:50:56:a0:d4:4a brd ff:ff:ff:ff:ff:ff

    inet 192.168.1.25/24 brd 192.168.1.255 scope global noprefixroute ens192

       valid_lft forever preferred_lft forever

    inet6 2400:4070:1b32:6100:250:56ff:fea0:d44a/64 scope global mngtmpaddr dynamic

       valid_lft 14381sec preferred_lft 14381sec

    inet6 fe80::250:56ff:fea0:d44a/64 scope link

       valid_lft forever preferred_lft forever

 

監視ホスト ネットワーク側 vNIC のネットワーク設定。

[root@lab-gw-01 ~]# ip address show ens224

3: ens224: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000

    link/ether 00:50:56:a0:d3:9b brd ff:ff:ff:ff:ff:ff

    inet 192.168.10.25/24 brd 192.168.10.255 scope global noprefixroute ens224

       valid_lft forever preferred_lft forever

    inet6 2400:4070:1b32:6100:250:56ff:fea0:d39b/64 scope global mngtmpaddr dynamic

       valid_lft 14293sec preferred_lft 14293sec

    inet6 fe80::250:56ff:fea0:d39b/64 scope link

       valid_lft forever preferred_lft forever

 

簡易的なルータとして動作するように、

firewalld を停止して、net.ipv4.ip_forward を有効「1」にしておきます。

[root@lab-gw-01 ~]# systemctl stop firewalld

[root@lab-gw-01 ~]# systemctl disable firewalld

[root@lab-gw-01 ~]# sysctl -w net.ipv4.ip_forward=1

 

vCenter / ESXi と監視ホストとのネットワーク接続性。

vSAN クラスタの vCenter / ESXi と、監視ホストとで

デフォルト ゲートウェイ設定だけではネットワーク接続できない場合は、

スタティック ルートを設定する必要があります。

 

たとえば、ESXi では下記のように esxcli でルーティングを設定できます。

[root@esxi-01:~] esxcli network ip route ipv4 add --network 192.168.10.0/24 --gateway 192.168.1.25

[root@esxi-01:~] esxcli network ip route ipv4 list

Network       Netmask        Gateway       Interface  Source

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

default       0.0.0.0        192.168.1.1   vmk0       MANUAL

192.168.1.0   255.255.255.0  0.0.0.0       vmk0       MANUAL

192.168.10.0  255.255.255.0  192.168.1.25  vmk0       MANUAL

 

また、vCenter Server Appliance では下記のように Appliance Shell(appliancesh)でルーティングを設定できます。

VMware vCenter Server Appliance 6.7.0.20000

 

Type: vCenter Server with an embedded Platform Services Controller

 

Last login: Sat Dec 15 13:19:46 2018 from 192.168.1.240

Connected to service

 

    * List APIs: "help api list"

    * List Plugins: "help pi list"

    * Launch BASH: "shell"

 

Command> networking.routes.add --prefix 24 --interface nic0 --destination 192.168.10.0 --gateway 192.168.1.25

Command> networking.routes.list

Routes:

  1:

      Static: False

      Destination: 0.0.0.0

      Interface: nic0

      Prefix: 0

      Gateway: 192.168.1.1

  2:

      Static: False

      Destination: 192.168.1.0

      Interface: nic0

      Prefix: 24

      Gateway: 0.0.0.0

  3:

      Gateway: 192.168.1.25

      Prefix: 24

      Destination: 192.168.10.0

      Interface: nic0

      Static: True

 

疑似的なネットワーク遅延の構成。

まず、vSAN と監視ホストとの間でネットワーク遅延が特にない状態です。

vsan-adv-d15-04.png

 

lab-gw-01 のゲスト OS で、tc コマンドを利用してネットワーク遅延を発生させます。

設定変更まえの、Linux ルータでの vNIC の状態です。

まだネットワーク遅延(delay)をエミュレーションする設定はありません。

[root@lab-gw-01 ~]# tc qdisc show dev ens192

qdisc pfifo_fast 0: root refcnt 2 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1

 

vSAN の健全性チェックにある「サイト遅延の健全性」の閾値が 500ms なので、

あえて 550ms の遅延を発生させてみます。

[root@lab-gw-01 ~]# tc qdisc add dev ens192 root netem delay 550ms

[root@lab-gw-01 ~]# tc qdisc show dev ens192

qdisc netem 8001: root refcnt 2 limit 1000 delay 550.0ms

 

vSAN の ESXi から監視ホストへ ping を実行しておくと、

設定した瞬間に、遅延が発生したことがわかります。

vsan-adv-d15-05.png

 

ネットワーク遅延がある環境なので、健全性チェックでも「再テスト」で警告となりました。

vsan-adv-d15-06.png

 

遅延設定は、下記のようなコマンドラインで解除できます。

[root@lab-gw-01 ~]# tc qdisc del dev ens192 root

 

設定すると、ネットワーク遅延が解消されます。

vsan-adv-d15-07.png

 

このように、手軽にネットワーク遅延のテストができたりします。

ネスト環境で、物理マシン 1台でこのような検証をする場合は、

今回のように物理マシン内にルータ役の VM も置いたりすることがあります。

 

つづく。

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

 

昨日はこちら。

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

 

14日目は、2ノード vSAN を 2セット展開しています。

ただし、本日の話題は 2 ノード vSAN 自体は直接的に関係ないもので

2 ノード vSAN を大量展開するときの Tips 紹介です。

  • vSAN-Cluster-20181214A クラスタ: 2 ノード vSAN
  • vSAN-Cluster-20181214B クラスタ: 2 ノード vSAN
  • 監視ホストの vSAN Witness Appliance は、データセンタにまとめて配置

 

2ノード vSAN は、ROBO(リモートオフィス / ブランチオフィス) や

エッジ コンピューティングでの利用が想定さたソリューションです。

そのため、大量に小規模クラスタを展開するケースにむけて

セットアップ作業の自動化、省力化に注目されることも多いようで、

PowerCLI スクリプトによる自動化 Tips も多く公開されています。

 

スクリプトを作成する場合には、2ノード vSAN の PowerCLI セットアップで

利用するコマンドラインは下記のような様子になります。(少し古い投稿ですが)

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

 

 

今回は、2セット構築した vSAN のひとつで、作業の省力化手法として

vSAN のプロアクティブ テスト機能のひとつである「仮想マシン作成テスト」を実行してみます。

vsan-adv-d14-01.png

 

テストは、「実行」ボタンから実行できます。

vsan-adv-d14-02.png

 

テストを実行した vSAN クラスタで、

ESXi ホストごとにテスト VM が作成 → 削除されます。

vsan-adv-d14-03.png

 

すべてのホストで成功しました。

このように、ただ正常に仮想マシンの作成 → 削除ができるか確認されます。

vsan-adv-d14-04.png

 

スクリプトなどでセットアップ処理を自動化しているような場合は、

PowerCLI からでも、このテストを実行できます。

 

テスト対象の vSAN クラスタです。

  • 今回の例では PowerCLI 11 を利用しています。
  • あらかじめ、Connect-VIServer で vCenter に接続ずみです。

PowerCLI> Get-Cluster vSAN-Cluster-20181214A | Get-VsanClusterConfiguration | ft -AutoSize

 

Cluster                VsanEnabled IsStretchedCluster Last HCL Updated

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

vSAN-Cluster-20181214A True        True               2018/12/14 2:57:00

 

 

テストを実行します。

Test Result が「Passed」と表示され、成功したことがわかります。

PowerCLI> Get-Cluster vSAN-Cluster-20181214A | Test-VsanVMCreation | ft -AutoSize

 

Cluster                Test Result Time of Test

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

vSAN-Cluster-20181214A Passed      2018/12/14 11:43:11

 

 

 

タイムスタンプから、vSphere Client 側にもテスト結果が反映されていることがわかります。

vsan-adv-d14-07.png

 

このように ボタン / コマンドひとつで手軽に VM 作成テストができるので、

vSAN デモ / ラボ環境を大量に作成するような場合にも

とりあえずの正常性確認に利用できそうかなと思います。

ただし、初期構築時のテストで利用するものとしておき、

本番運用を開始している vSAN で頻繁に実行するのは避けたほうがよいかなと思います。

 

つづく。

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

 

昨日はこちら。

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

 

13日目は、2ノード vSAN を、3ノード vSAN にしてみます。

vSAN は、12日のものを流用しています。

 

vSAN-Cluster-20181211 クラスタ(2 ノード → 3 ノード)

  • ESXi 2ノード → 3ノード
  • ハイブリッド(キャッシュ層 SSD + キャパシティ層 HDD)ディスクグループ
  • ディスクグループは各ノードで 1つずつ
  • フォールト ドメインは 2つ作成 → デフォルトに戻す。
  • vCenter は vSAN 外部に配置
  • vSAN ネットワークは外部ルーティングなし
  • vSAN Witness Appliance(監視ホスト)を配置 → 撤去
    • VMkernel ポートの vSAN Witness Traffic のタグは削除。

 

開始時点は 2ノード vSAN。

2ノード vSAN が構成されています。

この vSAN クラスタを 3ノード vSAN にします。

vsan-adv-d13-01.png

 

3ノード目の ESXi と、その実体の ESXi VM です。

3ノード目は vCenter に登録ずみですが、vSAN クラスタの外部にあります。

この ESXi も、他のノードと同様にネステッド ESXi によるものです。

追加した ESXi のネットワーク構成は、既存の 2台の ESXi に合わせてあります。

vsan-adv-d13-02.png

 

既存 2ノードの物理ケーブル結線の変更。

今回は、既存の 2ノードのネットワーク構成は特に変更していません。

 

本来であれば、2ノード間を直接接続してる構成の場合、

このあとの手順の前に、物理ネットワークのケーブル結線を変更します。

 

3ノード目も結線できるように、物理ネットワーク スイッチを介してノード間を接続することになります。

vSAN クラスタのホストを一旦停止するか

もしくは物理 NIC 片系ずつ差し替えなどの方法で、変更しておきます。

 

また、追加ノードと既存ノードとの ping などによる疎通確認も、

ここで実施しておきます。

 

vSAN ノードの追加。

(本番環境では)ここで vSAN 上の VM を一旦停止して、

前ホストをメンテナンスモードにしておくほうが無難です。

 

追加ノードで vSAN で利用するディスクで、

自動的にローカル データストアが作成されてしまうことがあります。

その場合、ローカル データストアは削除しておきます。

vsan-adv-d13-04.png

 

vSAN クラスタに、ノード#3 を追加します。

この時点ではまだ vSAN ディスクグループが作成されていないので、

手動で作成します。

vsan-adv-d13-05.png

 

今回のディスクグループは、ハイブリッド構成です。

vsan-adv-d13-06.png

 

ディスクグループが作成されました。

vsan-adv-d13-07.png

 

ストレッチ クラスタを「無効化」します。

これ以降は、「監視ホスト」が不要になります。

vsan-adv-d13-10.png

 

2ノード ストレッチクラスタ構成のために作成していたフォールトドメインは、

削除してしまいます。

vsan-adv-d13-13.png

 

これで、ESXi ホストそれぞれがフォールト ドメインのようになる、デフォルト構成に戻ります。

vsan-adv-d13-14.png

 

ESXi ホストから、vSAN Witness タグを削除します。

これは、SSH などで ESXi にログインして作業します。

削除前は、vmk0 に witness タグが付与されています。

[root@esxi-01:~] esxcli vsan network list

Interface

   VmkNic Name: vmk0

   IP Protocol: IP

   Interface UUID: 18f8105c-3ad7-e471-4708-005056a0bc23

   Agent Group Multicast Address: 224.2.3.4

   Agent Group IPv6 Multicast Address: ff19::2:3:4

   Agent Group Multicast Port: 23451

   Master Group Multicast Address: 224.1.2.3

   Master Group IPv6 Multicast Address: ff19::1:2:3

   Master Group Multicast Port: 12345

   Host Unicast Channel Bound Port: 12321

   Multicast TTL: 5

   Traffic Type: witness

 

Interface

   VmkNic Name: vmk1

   IP Protocol: IP

   Interface UUID: 2ef7105c-b8b0-d3fe-0e5a-005056a0bc23

   Agent Group Multicast Address: 224.2.3.4

   Agent Group IPv6 Multicast Address: ff19::2:3:4

   Agent Group Multicast Port: 23451

   Master Group Multicast Address: 224.1.2.3

   Master Group IPv6 Multicast Address: ff19::1:2:3

   Master Group Multicast Port: 12345

   Host Unicast Channel Bound Port: 12321

   Multicast TTL: 5

   Traffic Type: vsan

 

削除すると、vSAN トラフィックの vmk1 の表示だけが残ります。

もともと 2 ノード vSAN だった両方のホストから、witness タグを削除します。

[root@esxi-01:~] esxcli vsan network ip remove -i vmk0

[root@esxi-01:~] esxcli vsan network list

Interface

   VmkNic Name: vmk1

   IP Protocol: IP

   Interface UUID: 2ef7105c-b8b0-d3fe-0e5a-005056a0bc23

   Agent Group Multicast Address: 224.2.3.4

   Agent Group IPv6 Multicast Address: ff19::2:3:4

   Agent Group Multicast Port: 23451

   Master Group Multicast Address: 224.1.2.3

   Master Group IPv6 Multicast Address: ff19::1:2:3

   Master Group Multicast Port: 12345

   Host Unicast Channel Bound Port: 12321

   Multicast TTL: 5

   Traffic Type: vsan

 

vSphere Client 確認でも、vSAN タグだけになったことが確認できます。

vsan-adv-d13-15.png

 

vSAN Witness Appliance による監視ホストは、停止しておきます。

これで 2ノード vSAN が、3ノード vSAN になりました。

vsan-adv-d13-16.png

 

(本番では)ここで ESXi のメンテナンスモードを解除して、

VM を起動するとよいと思います。

 

拡張後の vSAN の様子。

監視ホストが削除されて vSAN ノードが追加されたことで、

vSAN オブジェクトの「監視」コンポーネントがリビルドされます。

vsan-adv-d13-19.png

 

そのため、構成変更直後は vSAN オブジェクトが「可用性が低下」となります。

ただしコンポーネント 2つが正常な状態なので、データにはアクセス可能な状態です。

vsan-adv-d13-18.png

 

リビルド タイマーを待つようですが、「今すぐ再同期」をすることもできます。

vsan-adv-d13-20.png

 

「監視」コンポーネントがリビルドされると、オブジェクトが正常になります。

vsan-adv-d13-21.png

 

vSAN 健全性テストでは「vSAN オブジェクトの健全性」がエラーになっていますが、

「再テスト」で解消されます。

vsan-adv-d13-22.png

 

ただし、ネスト環境なので、いくらか警告は残ります。

vsan-adv-d13-23.png

 

ノード(のディスクグループ)追加によって、自動的にデータストア容量が増加したことも確認できます。

vsan-adv-d13-24.png

 

ネステッド vSAN 環境で、2ノード → 3 ノード変更の練習をしてみる様子でした。

ちなみに、ノード #3 追加前にすべての ESXi VM で VM のスナップショットを取得しておくと

リトライしやすく検証が捗ると思います。

 

つづく。

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

 

昨日はこちら。

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

 

12日目は、昨日の 2ノード vSAN の補足として、

vSAN のデータ / 監視トラフィックを分離する「WTS」の構成にしてみました。

 

vSAN-Cluster-20181211 クラスタ(WTS 構成)

  • ESXi 2ノード
  • ハイブリッド(キャッシュ層 SSD + キャパシティ層 HDD)ディスクグループ
  • ディスクグループは各ノードで 1つずつ
  • フォールト ドメインは 2つ作成。
  • vCenter は vSAN 外部に配置
  • vSAN ネットワークは外部ルーティングなし(直接接続に近い)
  • vSAN Witness Appliance(監視ホスト)を配置
    • Witness Traffic Separation(WTS)構成

 

監視ホストと WTS の説明は、下記のあたりが参考になると思います。

 

ESXi ホスト側の WTS 構成の様子。

 

まず、ネスト環境かどうかに影響されない面での

WTS でのネットワーク構成の様子です。

 

vSAN ノード #1

VMkernel ポートの構成は、下記のようにしています。

vmk0、vmk1 は、それぞれ別の仮想スイッチに接続しています。

  • vmk0: vSwitch0 に接続。「vSAN 監視」トラフィック有効。
  • vmk1: vSwitch1 に接続。「vSAN」トラフィック有効。

このように、「vSAN」と「vSAN 監視」を使い分けて

vSAN のデータと監視のトラフィックを分離しているので「WTS」構成です。

 

2ノード構成だと「vSAN」によるデータ トラフィックを

ノード間で直接(物理スイッチなしで)ケーブル接続することがあり、

その場合は WTS 構成になります。

vsan-adv-d12-01.png

 

vmk0 と vmk1 が、それぞれ別の仮想スイッチに接続されている様子です。

物理アダプタは仮想スイッチごとに 1つずつしかありませんが、

実際に本番環境の物理マシンで構成する場合は

複数の物理 NIC でチーミングすることになります。

vsan-adv-d12-04.png

 

vSAN ノード #2

vSAN ノード #2 の VMkernel ポートの構成も、ノード #1 と同様です。

vmk0、vmk1 は、それぞれ別の仮想スイッチに接続しています。

  • vmk0: vSwitch0 に接続。「vSAN 監視」トラフィック有効。
  • vmk1: vSwitch1 に接続。「vSAN」トラフィック有効。

vsan-adv-d12-02.png

 

VMkernel ポートの仮想スイッチへの接続も、ノード #1 と同様です。

vsan-adv-d12-05.png

 

vSAN 監視ホスト

一方、vSAN クラスタ外部に配置してある監視ホストは、

vmk0 だけ利用し、「vSAN」トラフィックを有効にしています。

vmk1 は作成されていますが、ネットワークから切断して利用していません。

vsan-adv-d12-03.png

 

監視ホストでは、vmk0 のみネットワーク接続しています。

vmk1 を接続ている仮想スイッチ「witnessSwitch」は、

アップリンクの 物理アダプタ を切断してあります。

vsan-adv-d12-10.png

 

ネストの外側の仮想ネットワーク構成。

ESXi VM と、物理 ESXi ホスト側のネットワーク構成です。

 

vSAN ノードの ESXi VM である「vm-esxi-01」と「vm-esxi-01」、

そして監視ホストである「vm-esxi-w-01」を、vSwitch0 に接続しています。

これはネステッド ESXi 側では vmk0 にあたる接続です。

「vm-esxi-w-01」は 2の接続がありますが、

実際は ESXi VM で片方の vNIC を切断状態にしています。

vsan-adv-d12-07.png

 

この物理 ESXi のもうひとつの仮想スイッチを見てみます。

この vSwitch1 は、ネスト環境で vSAN(データ)トラフィックのための

ノード間の直接接続の役割を担当させるために作成しました。

 

こちらは、vSAN ノードの ESXi VM 2台だけが接続されていて、

監視ホストの ESXi VM は接続されていません。

そして、物理ネットワークアダプタ(物理 NIC)の接続もないので

物理 ESXi 内部だけで利用できるローカルスイッチです。

vsan-adv-d12-09.png

 

vSAN ノード側では vmk1 にあたる、

ESXi VM の 2つ目の vNIC「Network Adapter 2」が

接続されていることがわかります。

vsan-adv-d12-08.png

 

ネスト外側の ESXi VM の vNIC の MAC アドレスと、

ネスト内側の vSAN ノードでの vmk1 の MAC アドレスがことなるため、

この vSwitch1 でも「無差別モード」の通信を許可(承諾)しておきます。

vsan-adv-d12-12.png

 

ネステッド環境ではネットワーク構成の理解が難しいこともあると思いますが、

1台の物理マシンにネスト環境が収まる場合は、今回のように

物理 NIC を割り当てないローカル仮想スイッチを作成するという方法もあります。

 

つづく。

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

 

昨日はこちら。

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

 

11日目は、2ノード vSAN を構成してみました。

 

vSAN-Cluster-20181211 クラスタ

  • ESXi 2ノード
  • ハイブリッド(キャッシュ層 SSD + キャパシティ層 HDD)ディスクグループ
  • ディスクグループは各ノードで 1つずつ
  • フォールト ドメインは 2つ作成。
    • Preferred: ESXi 1ノード
    • Secondary: ESXi 1ノード
  • vCenter は vSAN 外部に配置
  • vSAN Witness Appliance(監視ホスト)を配置

 

ESXi が 2ノードの vSAN クラスタです。

2 ノード vSAN を構成した際は、vSAN の健全性テストの「ストレッチ クラスタ」が

すべて緑になっているか確認しておきます。

vsan-adv-d11-01.png

 

vSAN Witness アプライアンスをデプロイして、監視(Witness)ホストにしています。

監視ホストは必ず、監視対象にする vSAN クラスタの外部に配置します。

監視ホストも、他の ESXi と同じバージョンで ESXi 6.7 U1 です。

ホストのアイコンは、他の ESXi とは異なり水色です。

vsan-adv-d11-02.png

 

vSAN Witness Appliance による監視ホスト「192.168.1.29」の実体となる ESXi VM です。

これまでもネステッド ESXi による vSAN を構成していましたが、

Witness Appliance は、VMware から仮想アプライアンスの ova ファイルとして提供されています。

デプロイ先の互換性を考慮してか、仮想マシンバージョンは少し古めです。

vsan-adv-d11-03.png

 

vSAN の設定では、ストレッチ クラスタが有効になっています。

2ノード vSAN の実態は、2フォルト ドメイン + 監視ホストによるストレッチ クラスタです。

フォールト ドメインは 2つ作成しされ、それぞれ ESXi が 1ホストだけ含まれます。

「1件のフォールト ドメイン障害」が許容される、というのは

1ノードの ESXi ホスト障害に耐えられるということです。

vsan-adv-d11-04.png

 

2ノード vSAN での VM のデータ配置は、オブジェクトを構成する「監視」コンポーネントが

監視ホストに配置されます。

vsan-adv-d11-05.png

 

2 ノード vSAN は、vSAN としては応用的な構成だと思うので、

ラボ環境の構築のやりがいがあるかなと感じます。

 

つづく。

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

 

昨日はこちら。

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

 

10日目は、6ノードのオールフラッシュ vSAN を構成してみました。

 

vSAN-Cluster-20181210 クラスタ

  • ESXi 6ノード
  • オール フラッシュ(キャッシュ層 SSD + キャパシティ層 SSD)ディスクグループ
  • ディスクグループは各ノードで 1つずつ
  • 重複排除・圧縮 は無効のまま
  • フォールト ドメインはデフォルト構成のまま
  • vCenter は vSAN 外部に配置

 

vSAN では 6ノードのオールフラッシュ ディスクグループ構成にすると、

仮想マシン ストレージ ポリシーによる RAID 6 が利用できるようになります。

 

RAID 6 の仮想マシン ストレージ ポリシーを作成します。

vsan-adv-d10-01.png

 

6ノードのオールフラッシュ vSAN に配置した VM「vm01」にポリシーを適用しました。

vsan-adv-d10-05.png

 

vm01 の vSAN オブジェクトを見ると、コンポーネントが RAID 6 になっています。

vsan-adv-d10-02.png

 

RAID 6 では、2ノードの障害まで、データの可用性が保たれるので、

2ホストの ESXi 停止してみます。

ネストの外側の ESXi VM を 2台同時にパワーオフします。

このとき、vm01 が起動している ESXi は避けます。

vsan-adv-d10-06.png

 

パワーオフ。

vsan-adv-d10-07.png

 

ESXi VM がパワーオフされました。

vsan-adv-d10-08.png

 

vSphere Client を見ていると、徐々に障害の様子が表示されます。

vsan-adv-d10-09.png

 

vSAN コンポーネントは、ちゃんと2重の障害になっています。

vsan-adv-d10-12.png

 

vm01 のゲスト OS でディスクへの書き込みをしていたところ、

疑似障害の(ESXi 2台をパワーオフした)タイミングで、数秒の I/O 停止がみられますが、

VM は停止せず、その後も書き込みが続けられています。

vsan-adv-d10-10.png

 

ちなみに、3ノード以上を停止させると、すぐに書き込みができなくなるはずです。

 

つづく。

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

 

昨日はこちら。

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

 

9日目は、8日目の vSAN 構成のうち、キャパシティ層 HDD を SSD に変更してみます。

 

vSAN-Cluster-20181209 クラスタ

  • ESXi 4ノード
  • オール フラッシュ(キャッシュ層 SSD + キャパシティ層 SSD)ディスクグループ
  • ディスクグループは各ノードで 1つずつ
  • 重複排除・圧縮 は無効のまま
  • フォールト ドメインはデフォルト構成のまま
  • vCenter は vSAN 外部に配置

 

vSAN では、ディスクグループを All-Flash 構成にすることで

利用可能になる機能があります。

今回は、仮想マシン ストレージ ポリシーによる RAID 5 を構成してみます。

 

vSAN で RAID 5 を構成するには、4つ以上のフォールト ドメインと、

オール フラッシュのディスクグループが必要です。

 

参考:

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

 

フォールト ドメイン については、デフォルトでは

ESXi ホストがそれぞれフォールト ドメインとして扱われます。

そのため 4ノードの vSAN であれば、4つのフォールト ドメインが存在することになります。

vsan-adv-d08-08.png

 

ハイブリッド構成での RAID 5 構成。

まず、昨日の ハイブリッド構成で RAID 5 の構成を試みてみます。

これは要件を満たさない構成なので、失敗するはずです。

 

8日のクラスタは、4ノードですが、ハイブリッド構成(キャパシティ層が HDD)です。

vsan-adv-d08-03.png

 

RAID 5 の仮想マシンストレージ ポリシー「vSAN-Policy_RAID5」を作成しました。

vsan-adv-d08-01.png

 

VM「vm01」に「vSAN-Policy_RAID5」ポリシーを適用しようとすると、

(SSD の)キャパシティ層ディスクが足りないという警告メッセージが表示されます。

警告メッセージからはわかりにくいですが、

SSD のキャパシティ ディスクが不足している(ゼロ個しかない)ということで

実際に適用しようとしてもエラーで適用できません。

vsan-adv-d08-02.png

 

 

オールフラッシュ構成での RAID 5 構成。

それではオールフラッシュ構成の 4ノード vSAN で、RAID 5 を構成してみます。

 

キャパシティ層が SSD(フラッシュ)の、4ノード vSAN です。

vsan-adv-d08-04.png

 

VM「vm02」に、先ほど作成した RAID 5 のポリシーを適用します。

vsan-adv-d08-05.png

 

この構成であれば、先ほどの「vSAN-Policy_RAID5」ポリシーを選択しても

特に警告メッセージは表示されません。

vsan-adv-d08-06.png

 

「vSAN-Policy_RAID5」ポリシーを適用することができ、

ポリシーのコンプライアンスも「準拠」になりました。

vsan-adv-d08-09.png

 

vm02 の vSAN オブジェクトも、コンポーネントが RAID 5 の状態になっています。

vsan-adv-d08-07.png

 

オールフラッシュ構成ならではの vSAN の機能を、

ネステッド ESXi による、疑似的なオールフラッシュ vSAN で構成してみました。

 

つづく。

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

 

昨日はこちら。

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

 

8日目は、1日目に近い構成の vSAN ですが、キャパシティ層 HDD の容量に注目してみます。

 

vSAN-Cluster-20181208 クラスタ

  • ESXi 4ノード
  • ハイブリッド(SSD + HDD)ディスクグループ
    • キャパシティ層 の HDD は 200GB
  • ディスクグループは各ノードで 1つずつ
  • 重複排除・圧縮 は無効のまま
  • フォールト ドメインはデフォルト構成のまま
  • vCenter は vSAN 外部に配置

 

下記のように、キャパシティ層を 200GB の HDD にしています。

vsan-adv-d08-01.png

 

実は vSAN には、仮想ディスクのコンポーネントごとの最大容量が設定されています。

これは ESXi ごとのパラメータ「VSAN.ClomMaxComponentSizeGB」で、

デフォルトでは 255GB です。

vsan-adv-d08-02.png

 

このパラメータについては、下記の KB でも案内されています。

 

vSAN に小容量の磁気ディスクを使用すると仮想マシン障害が発生する場合がある (2080503)

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

https://kb.vmware.com/s/article/2080503?lang=ja (日本語)

 

VSAN.ClomMaxComponentSizeGB は、上記の vSphere Client 画面で

設定変更をすることができますが、ここからは

PowerCLI でこのパラメータの設定、設定確認をしてみます。

 

今回利用するバージョンは、PowerCLI 11 ですが、

古いバージョンの PowerCLI でも同様の操作が可能なはずです。

また、PowerCLI では、vCenter に接続ずみです。

 

vSAN クラスタには、4 ノードの ESXi ホストが接続されています。

PowerCLI> Get-Cluster vSAN-Cluster-20181208 | Get-VMHost | Sort-Object Name | ft -AutoSize Name,Version,ConnectionState

 

Name         Version ConnectionState

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

192.168.1.31 6.7.0         Connected

192.168.1.32 6.7.0         Connected

192.168.1.33 6.7.0         Connected

192.168.1.34 6.7.0         Connected

 

 

デフォルトでは255 GB になっています。

PowerCLI> Get-Cluster vSAN-Cluster-20181208 | Get-VMHost | Sort-Object Name | Get-AdvancedSetting -Name VSAN.ClomMaxComponentSizeGB | select Entity,Name,Value

 

Entity       Name                        Value

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

192.168.1.31 VSAN.ClomMaxComponentSizeGB   255

192.168.1.32 VSAN.ClomMaxComponentSizeGB   255

192.168.1.33 VSAN.ClomMaxComponentSizeGB   255

192.168.1.34 VSAN.ClomMaxComponentSizeGB   255

 

 

下記のようにパラメータを変更できます。

PowerCLI> Get-VMHost 192.168.1.31 | Get-AdvancedSetting -Name VSAN.ClomMaxComponentSizeGB | Set-AdvancedSetting -Value 180 -Confirm:$false

PowerCLI> Get-Cluster vSAN-Cluster-20181208 | Get-VMHost | Sort-Object Name | Get-AdvancedSetting -Name VSAN.ClomMaxComponentSizeGB | select Entity,Name,Value

 

Entity       Name                        Value

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

192.168.1.31 VSAN.ClomMaxComponentSizeGB   180

192.168.1.32 VSAN.ClomMaxComponentSizeGB   255

192.168.1.33 VSAN.ClomMaxComponentSizeGB   255

192.168.1.34 VSAN.ClomMaxComponentSizeGB   255

 

 

また、下記のように複数の ESXi のパラメータをまとめて変更することもできます。

PowerCLI> Get-Cluster vSAN-Cluster-20181208 | Get-VMHost | Get-AdvancedSetting -Name VSAN.ClomMaxComponentSizeGB | Set-AdvancedSetting -Value 180 -Confirm:$false

 

Name                 Value                Type                 Description

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

VSAN.ClomMaxCompo... 180                  VMHost

VSAN.ClomMaxCompo... 180                  VMHost

VSAN.ClomMaxCompo... 180                  VMHost

VSAN.ClomMaxCompo... 180                  VMHost

 

 

ただしこのパラメータは最小値が 180GB で、

179GB 以下を設定しようとするとエラーになってしまいます。

[root@esxi-01:~] vmware -vl

VMware ESXi 6.7.0 build-10302608

VMware ESXi 6.7.0 Update 1

[root@esxi-01:~] esxcli system settings advanced list -o /VSAN/ClomMaxComponentSizeGB

   Path: /VSAN/ClomMaxComponentSizeGB

   Type: integer

   Int Value: 180

   Default Int Value: 255

   Min Value: 180

   Max Value: 255

   String Value:

   Default String Value:

   Valid Characters:

   Description: Maximum component size used for new placements

 

キャパシティ層で 255GB がおさまらない小容量のディスクを利用することは

本番環境での vSAN では殆どないと思いますが、ネスト環境では

小容量の VMDK をキャパシティ層として構成することがあります。

検証などでコンポーネントが意図した配置にならないことがあったら、

このパラメータを調整してみるとよいかもしれません。

 

ちなみに私がネステッド vSAN を利用する場合は、

あまり大容量ではない VM を利用したり、

ネストの外側の VMDK をシン プロビジョニングで大きめに用意したり

といったことが多く、あまりこのパラメータの変更をしていません・・・

 

つづく。

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

 

昨日はこちら。

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

 

前回は、vSAN のディスク構成によってシステム要件が変わる様子を見てみました。

今回は、vSAN データストアの構成を完了するわけではなく、

ESXi ホスト単体でディスクグループを作成するだけです。

単純な興味から、「上限値を超えることができるのか」を

ネスト環境を利用して試してみます。

 

vSAN を有効化したクラスタ「vSAN-Cluster-20181207」に参加させた

ESXi ホスト「192.168.1.31」の HDD 数を、

ディスクグループあたりのキャパシティ層 HDD 数の上限を超える「8」にしています。

vsan-adv-07-01.png

 

vSAN 6.7 でのディスクグループあたりのキャパシティ層ディスクの上限は、

「7」となっています。

vsan-adv-07-00.png

 

そこで、上限数をこえる HDD 数で vSAN ディスクグループを作成したら

どうなるのか試してみます。

 

実験1。

vSAN ディスクグループを、キャパシティ層ディスク数 8で作成してみます。

 

はじめは、ディスクグループが未作成の状態です。

vsan-adv-07-02.png

 

キャパシティ層の HDD を 8つ指定して、ディスクグループを作成してみます。

vsan-adv-07-03.png

 

ディスクグループの作成自体は、完了できてしまいました。

vsan-adv-07-04.png

 

キャパシティ層である「容量」ディスクを見ると、7つ含まれています。

そして「mpx.vmhba0:C0:T5:L0」という名前の HDD が、含まれていません。

自動的に、上限数までのディスクでディスクグループが作成されたようです。

vsan-adv-07-05a.png

vsan-adv-07-06a.png

 

実験2。

今度は、キャパシティ層ディスク数 7 の vSAN ディスクグループに、さらにディスクを追加してみます。

実験1 で作成したディスクグループに、8つ目の HDD として「mpx.vmhba0:C0:T5:L0」を追加します。

vsan-adv-07-07.png

 

追加処理は開始されますが、今度は「Too many disks」エラーになり失敗しました。

「ディスクグループあたりのキャパシティ層ディスク数」は、ハード リミットのようです。

vsan-adv-07-09.png

 

上限値を超える構成はそもそも設計時点で避けるべきですが、

うっかり上限を超える構成にしようとしてしまうこともあると思います。

vSphere ではツールによっては、非サポート / 非推奨の設定にできてしまったり

制限値によっては、上限値を超える設定が可能なことがあります。

そういった際に、ネスト環境でのデバイス追加は、物理環境よりも容易なことが多く

物理マシンとして用意しにくいハードウェア構成でも手軽に用意できます。

万一のうっかり構成時の挙動や、単純な興味によるものの確認もしやすいかなと思います。

 

つづく。

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

 

昨日はこちら。

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

 

6日目は、vSAN のキャパシティ層 HDD の搭載数を増やしてみました。

ラボ構築などで極端にスペックの低いマシン構成にする場合などでは

ディスク構成によって ESXi の搭載メモリ容量の考慮が必要です。

そこで今回は意図的に、メモリ不足になる状態でディスク グループ作成をしてみます。

 

vSAN-Cluster-20181206 クラスタ

  • Hybrid ディスク グループ vSAN
  • キャッシュ層 SSD x 1
  • キャパシティ層 HDD x 3

 

今回の ESXi ホストは、 キャパシティ層むけに HDD を 3つずつ搭載しています。

vsan-adv-06-01.png

 

この時点では、vSAN ディスクグループが未作成の状態です。

vsan-adv-06-02.png

 

そして、キャパシティ層の HDD を 3つ指定して、

vSAN ディスクグループを作成してみます。

vsan-adv-06-03.png

 

しかし、ディスクグループ作成は下記のようなエラーで失敗してしまいます。

実は vSAN を構成するにあたり、ディスクグループに含めるデバイスの構成によって

ESXi のメモリ容量の要件が異なります。

この環境では、ネステッド vSAN ということもあり

ESXi に搭載しているメモリ容量が、極端に少なくなっています。

そのため、そのメモリ容量での上限である HDD 数(2つ)を超えてしまいエラーとなります。

vsan-adv-06-04.png

 

ネストの外側での、ESXi VM を見てみます。

ディスクグループ作成でエラーを発生させた時点では、

6GB しかメモリを割り当てていませんでした。

vsan-adv-06-05.png

 

そこで VM を停止して、メモリ容量を 8GB に変更しました。

VM(ESXi)を起動するだけで、ESXi は変更後のメモリ容量を認識します。

vsan-adv-06-06.png

 

あらためて、キャパシティ層 HDD が 3つの vSAN ディスクグループを作成します。

vsan-adv-06-07.png

 

今度は、ディスクグループを作成できました。

vsan-adv-06-09.png

 

キャッシュ層 SSD x 1 と キャパシティ層 x 3 で、合計 4 ディスクです。

vsan-adv-06-08.png

 

このように、vSAN ディスクグループ数や、そのディスク構成によって

ESXi で必要なメモリ容量が異なります。

実際に物理マシンで vSAN を構成するときにこの制限が問題になることは少ないと思いますが、

ラボ環境の準備や、いわゆる vSAN によるオーバーヘッドとなる容量の見込みなどで

注意が必要になることもあるかなと思います。

 

ちなみに、vSAN ディスクグループの最大構成である

5ディスクグループ で、それぞれ 7キャパシティ層 HDD を搭載する場合は、

vSAN で使用する容量として最小でも 32GB のメモリが必要とされています。

 

以下、vSAN 6.7 のドキュメントより。

vSAN のハードウェア要件

メモリ

 

vSAN のメモリ要件は、ESXi ハイパーバイザーによって管理されるディスク グループと

デバイスの数によって決まります。各ホストには、最大で 5 個のディスク グループと、

ディスク グループあたり最大で 7 個のキャパシティ デバイスに対応できるよう、

最小でも 32 GB のメモリを搭載する必要があります。

 

つづく。

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

 

昨日はこちら。

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

 

5日目は、キャパシティ層 HDD の搭載数が異なるネステッド vSAN を用意してみました。

これで、ストライプ数が異なる 仮想マシン ストレージ ポリシー の動作確認などができます。

  • vSAN-Cluster-20181203a クラスタ
    • Hybrid ディスク グループ vSAN
    • キャッシュ層 SSD x 1
    • キャパシティ層 HDD x 1
  • vSAN-Cluster-20181205 クラスタ
    • Hybrid ディスク グループ vSAN
    • キャッシュ層 SSD x 1
    • キャパシティ層 HDD x 2

 

キャパシティ層 のデバイス数が異なるディスクグループの様子。

vSAN-Cluster-20181203a クラスタ

このクラスタの ESXi ホストは最小ディスク数の構成で、

キャパシティ層の HDD を 1つだけ搭載しています。

 

vSphere Client で確認すると、ディスクグループあたりのディスク数は 2 で、

ディスクグループの HDD(80GBのもの) は 1つだけです。

vsan-adv-05-01.png

vSAN-Cluster-20181205 クラスタ

このクラスタの ESXi ホストは、

キャパシティ層の HDD を2つ搭載しています。

 

ディスクグループあたりのディスク数は 3 で、

ディスクグループの HDD は 2つです。

vsan-adv-05-02.png

 

ネストの外側の ESXi VM の構成をみると、キャパシティ層 HDD が 1つの ESXi VM では

80GB のディスクが 1つだけ接続されています。

vsan-adv-05-03.png

 

一方、キャパシティ層 HDD が 2つの ESXi VM では

80GB のディスクが 2 つ接続されています。

vsan-adv-05-04.png

 

仮想マシン ストレージ ポリシーでのストライプ数変更。

キャパシティ層のデバイス数が複数ある状態ならではの動作確認のため、

ストライプ数を 2に設定した 仮想マシン ストレージ ポリシー「vSAN-Policy_Stripe-2」を作成してみます。

vsan-adv-05-07.png

 

vSAN-Cluster-20181203a クラスタの VM「vm-stripe-1」は、

デフォルトのポリシーのままにしてあります。

vsan-adv-05-08.png

 

一方、vSAN-Cluster-20181205 クラスタの VM「vm-stripe-2」には、

新規作成した、ストライプ数 2 のポリシーを設定しました。

vsan-adv-05-09.png

 

まず、デフォルトのポリシー(ストライプ数 1)を適用している VM です。

仮想ディスクは RAID 1 となり、コンポーネントを2か所に格納しています。

vsan-adv-05-05.png

 

そして、ストライプ数 2 のポリシーを適用した VM です。

この VM は、「キャパシティ層 HDD 2つ」の vSAN に配置してあります。

仮想ディスクは RAID 1 でコンポーネントを2か所に格納し、

ストライプ(RAID 0)で、さらに2か所に分散して格納しています。

vsan-adv-05-06.png

 

ちなみに、キャパシティ層 HDD が 1つだけの 3ノード vSAN だと

ストライプのデータを書き込むデバイス数がたりないため、

仮想マシンに ストライプ数 2 のポリシーを適用しようとしてもエラーになってしまいます。

ポリシーを変更する画面で警告が表示され・・・

vsan-adv-05-10.png

 

そのまま設定しようとしてもエラーになります。

vsan-adv-05-11.png

 

ネステッド vSAN であれば ESXi のディスク搭載数も

ESXi VM での VMDK 追加 / 削除だけで変更できるので、

実機での vSAN の挙動確認が容易になります。

 

つづく。

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

 

昨日はこちら。

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

 

4日目は、All-Flash / Hybrid の vSAN をそれぞれ作成してみる話です。

それぞれ 3ノードで、All-Flash と Hybrid のネステッド vSAN を用意してみました。

  • vSAN-Cluster-20181203a クラスタ → Hybrid ディスク グループ の vSAN
  • vSAN-Cluster-20181203b クラスタ → All Flash ディスク グループ の vSAN

 

All-Flash / Hybrid の見え方。

vSAN-Cluster-20181203a クラスタ

ディスクグループがハイブリッド構成(キャッシュ層が SSD +  キャパシティ層が HDD)の vSAN です。

キャパシティ層のデバイスは、「ディスク層」が「容量」と表示されています。

クラスタ内の ESXi では、ディスクグループの種類は揃えます。

vsan-adv-04-01.png

 

vSAN-Cluster-20181203b クラスタ

ディスクグループがオールフラッシュ構成(キャッシュ層が SSD + キャパシティ層も SSD)の vSAN です。

こちらも、クラスタ内の ESXi では、ディスクグループの種類は揃えます。

vsan-adv-04-02.png

 

ストレージデバイスの SSD / HDD 切り替え。

実は vSphere では、ESXi に接続されたストレージ デバイスを

SSD / 非 SSD(HDD)と識別させる方法があります。

 

ネステッド vSAN 環境の場合、外側の物理マシンに搭載したストレージ デバイスによって

ネスト側の ESXi VM のデバイスも認識がかわります。

しかし、その認識にかかわらず強制的に SSD / 非 SSD と認識させることで

疑似的に All-Flash / Hybrid vSAN を構成することができます。

この設定で性能面で変化があるわけではありませんが、

All-Flash 限定の機能を検証することができるようになります。

 

ストレージ デバイスの SSD / 非 SSD の認識は、ESXi の

設定 → ストレージ デバイス 画面で設定できます。

 

もともとドライブのタイプが「フラッシュ」(SSD)と認識されているデバイスでは、

「HDD ディスクとしてマーク」ボタンが表示されます。

vsan-adv-04-05.png

 

一方、ドライブのタイプが「HDD」と認識されているデバイスでは、

「フラッシュ ディスクとしてマーク」ボタンが表示されるので、

これで SSD としてマークできます。

vsan-adv-04-06.png

 

SSD / HDD マークの仕組み。

ESXi での SSD / 非 SSD マークには、

ストレージ アレイ タイプ プラグイン (SATP)という仕組みが利用されています。

ストレージ デバイスの種類を指定できるルールを付与することで、

 

Hybrid ディスクグループに含まれる、HDD と認識されたデバイスでは、

Options が disable_ssd となっているルールが設定されています。

vsan-adv-04-07.png

 

一方、All-Flash ディスクグループに含まれる、ストレージ デバイスでは、

キャッシュ層 / キャパシティ層 の両方のデバイスに enable_ssd が設定されています。

vsan-adv-04-08.png

 

本来であれば SSD / HDD を正しく認識させるための機能のはずですが、

このように、ネステッド vSAN では、物理ストレージの種類にかかわらず

All-Flash / Hybrid のラボ環境を構成することに利用できます。

 

つづく。