Skip navigation
1 2 3 Previous Next

にほんごVMware

350 posts

今月は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 のラボ環境を構成することに利用できます。

 

つづく。

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

 

昨日はこちら。

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

 

3日目も、3ノード vSAN クラスタを構成します。

しかし今回は、vCenter 配下に同時に 2クラスタを構成してみます。

  • ESXi は 3ノード
  • vCenter は vSAN 外部に配置
  • vCenter 配下に vSAN クラスタを 2つ構成

 

3ノード クラスタ「vSAN-Cluster-20181203a」と「vSAN-Cluster-20181203b」で

それぞれ vSAN を構成しています。

 

vSAN-Cluster-20181203a クラスタ

※vSAN クラスタと、対応する ネストの ESXi VM に赤枠をつけています。

vsan-adv-03-01.png

 

vSAN-Cluster-20181203b クラスタ

vsan-adv-03-02.png

 

vSAN クラスタごとに、vSAN データストアが作成されます。

デフォルトのデータストア名は「vsanDatastore」です。

vsan-adv-03-03.png

 

1番目以降のデータストア名は「vsanDatastore (1)」というように

データストア名が重複しないように、自動的に数字が付与されます。

これは従来のデータストアと同様です。

vsan-adv-03-04.png

 

vSAN では、vSAN データストアの共有は、必ずクラスタ内でのものとなります。

vSAN データストアの「ホスト」タブには、

その vSAN クラスタ内のホストのみが表示されます。

クラスタをまたいだホストが vSAN データストアに VM を配置することはありません。

vsan-adv-03-05.png

 

もう片方の vSAN データストアも同様です。

vsan-adv-03-06.png

 

ちなみに vSAN データストア名は、

従来のデータストアと同様に右クリックなどから名前を変更できます。

vsan-adv-03-07.png

 

複数の vSAN データストアがある場合は

自動付与された名前のままではなく、どのクラスタのものか

わかりやすい名前にしておくと運用しやすいかなと思います。

vsan-adv-03-08.png

 

ネステッド vSAN であればオーバーコミットで ESXi を用意できるため

このように物理マシンでは用意しにくい台数構成の検証も容易です。

 

つづく。

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

 

昨日はこちら。

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

 

2日目は、vSAN の最小構成とされる 3ノード クラスタを構成します。

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

 

vSAN ではデフォルト(の仮想マシンストレージポリシー)だと、

データは、3ノード(コンポーネント x 2 と 監視 x 1)に分散配置されます。

 

下記は昨日の 4ノード vSAN ですが、VM「vm01」の 3オブジェクト

VM Home(.vmxファイルなど)、Hard Disk 1(VMDK ファイル)、SWAP オブジェクト

がそれぞれ 3ノードに分散されている様子がわかります。

vsan-adv-02-01.png

 

3ノード vSAN だと、1ノードで障害が発生した場合でも

データの可用性がある(データを読み書きできる)のですが、

ノード障害中はリビルドができないため、その間に 2台目のノード障害があると

悲しいことになってしまいます。

 

4ノード vSAN の、1ノード障害。(昨日の vSAN にて)

4ノード以上の vSAN であれば、1ノードの障害が発生した場合でも

デフォルトで 60分後にデータがリビルドされます。

 

ためしに、1ノードで疑似障害を発生させてみます。

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

 

このときのポイントは下記です。

  • VM のデータが配置されているノードを選択する。
  • VM が起動しているノードは選択しない。
    (VM が稼働継続する様子が見られるように)

vsan-adv-02-02.png

 

少し待って vSphere Client を更新すると、1ノード障害の様子が確認できます。

今回は「192.168.1.32」という ESXi を強制停止したので、

そのノード(ホスト)に配置されているデータに問題が発生します。

VM が起動しているノードを停止したわけではないので

「vm01」は、そのまま稼働継続できています。

vsan-adv-02-07.png

 

監視 → vSAN → 健全性

でもアラートが表示されます。

障害直後は「可用性が低下(再構築なし)- 遅延タイマー」に計上されています。

vsan-adv-02-05.png

 

これは、過剰なデータ移動を避けるように「オブジェクト修復タイマー」で指定されている

時間「60分間」は、リビルドを待機するためです。

vsan-adv-02-08.png

 

これは、「オブジェクトの再同期」画面でもわかります。

vsan-adv-02-09.png

 

VM が 1つだけなのに「~ 遅延タイマー」が 3件 となっているのは、

この VM が 3つの vSAN オブジェクトを持っているためです。

vsan-adv-02-06.png

 

60分以上経過すると自動的に正常なノードでリビルドされ、データが健全な状態になります。

vsan-adv-02-13.png

 

「vm01」のオブジェクトがすべて健全になりました。

vsan-adv-02-11.png

 

障害ノード「192.168.1.32」に配置されていたコンポーネントが、

正常ノード「192.168.1.31」にリビルドされています。

vsan-adv-02-12.png

 

3ノード vSAN の、1ノード障害。

一方、3ノード vSAN でノード障害が発生した場合には、

障害ノードを復旧するまでリビルドができません。

 

3ノード vSAN を構築しました。

vsan-adv-02-14.png

 

そして疑似障害を発生させるため、ネストの外側から ESXi VM をパワーオフします。

vsan-adv-02-15.png

 

3ノード vSAN でも、4ノードの場合と同様に VM は稼働継続したまま、

障害ノードのデータにはアクセスができなくなります。

vsan-adv-02-16.png

 

そしてリビルドの遅延タイマーを待ちます。

vsan-adv-02-17.png

 

しかし、60分以上経過しても、正常ノードの台数が不足したままなので

リビルドはされません。

「可用性が低下(再構築なし)- 遅延タイマー」はゼロ件になり、

「可用性が低下(再構築なし)」が 3件になります。

vsan-adv-02-19.png

 

障害ノードを何とか復旧するまで、不安な状態となります。

当然ながら、障害ノードを復旧すると自動的にデータは健全な状態になります。

vsan-adv-02-22.png

 

そのため、vSAN は 4ノード以上にしておくと、

1ノード障害時にも落ち着いて復旧作業をすることができます。

 

つづく。

本番環境に vSAN を導入するときには厳密にハードウェア互換性などを

確認する必要があります。

しかしその反面、動作確認、機能検証、デモンストレーションといった用途のためであれば

手軽なネステッド環境で vSAN を構築することができます。

 

そこで今月は1日1回くらい、

ネステッド環境で、さまざまな vSAN を構成してみようと思います。

ソフトウェア バージョンは vSAN 6.7 u1 を利用するつもりです。

 

ネステッド vSAN と、その構築方法については下記もどうぞ。

図解 ネステッド vSAN ラボ。

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

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

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

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

 

1日目は、vSAN の基本操作・動作を確認しやすい

下記の構成のネステッド vSAN を構築してみました。

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

 

それでは、構成したネステッド vSAN 環境を

vSphere Cilent でひととおり見てみます。

 

ネストの外側と、ネストの内側。

ネステッド vSAN を構成する ESXi は、VM です。

「ネストの外側」から実体の VM を見ると、ゲスト OS が VMware ESXi になっています。

vsan-adv-01-02.png

 

一方「ネストの内側」となるハイパーバイザから見ると、

サーバのモデルが「VMware Virtual Platform」です。

vsan-adv-01-03.png

 

ネステッド vSAN で主な画面を眺める。

ネステッド vSAN の UI を表示してみます。

vSAN 6.7 U1 では、基本的に HTML5 版の vSphere Client  から

操作できるようになっています。(Flash 版の vSphere Web Client ではなく)

 

設定 → vSAN → サービス

今回はデフォルトで無効なものは、そのままです。

vsan-adv-01-04.png

 

設定 → vSAN → ディスク管理

各ノードには、1ディスクグループ(キャッシュ用 SSD 1つ、キャパシティ用 HDD 1つ)

が作成されています。

vsan-adv-01-05.png

 

設定 → vSAN → フォールト ドメイン

フォールトドメインはデフォルトのままで特に構成していないので

各ノードそれぞれがフォールトドメインとなっています。

vsan-adv-01-06.png

 

設定 → vSAN → iSCSI ターゲット サービス

vSAN iSCSI ターゲットも無効のままです。

vsan-adv-01-07.png

 

監視 → vSAN → 健全性

ネステッド環境はそもそも商用環境でサポートされておらず

ハードウェア互換性も無視するものなので、そのぶんエラー警告などは表示されます。

そのため検証目的やデモ内容とは直接関係ないものは、わりきって無視します。

vsan-adv-01-08.png

 

監視 → vSAN → 仮想オブジェクト

vsan-adv-01-09.png

 

監視 → vSAN → 物理ディスク

vsan-adv-01-10.png

 

監視 → vSAN → オブジェクトの再同期

vsan-adv-01-11.png

 

監視 → vSAN → プロアクティブ テスト

vsan-adv-01-12.png

 

監視 → vSAN → 容量

vSAN データストアでは、ESXi VM に割り当てた VMDK ファイルの容量が認識されます。

そのため ネステッド ESXi に接続する VMDK をシン プロビジョニングにしておけば、

外側の物理マシンのストレージ容量を超えた、大容量 vSAN のデモ環境も作成できます。

vsan-adv-01-14.png

 

監視 → vSAN → パフォーマンス

vsan-adv-01-15.png

 

監視 → vSAN → パフォーマンス診断

vsan-adv-01-16.png

 

監視 → vSAN → サポート

vsan-adv-01-17.png

 

このように、基本操作や画面確認であれば、

ネステッド vSAN でも、通常の vSAN 同等に利用可能です。

VMware の提供するオンラインのハンズオン ラボでも

ネステッド vSAN が利用されています。

 

つづく。

日本の vExperts Advent Calendar 2018 の 1日目の投稿です。

 

vExperts Advent Calendar 2018

https://adventar.org/calendars/3101

 

1日目なのでクリスマス色のつよい Tips をお伝えしたいと思います。

そこで、lamw さんの Tips を参考に vSphere Client の色を変更してみます。

Add custom color to vSphere HTML5 UI Header/Footer in vSphere 6.7 Update 1 · GitHub

 

当然ながら HTML5 のハックは非サポートですので、

自宅ラボなどで気分を出すためにご利用いただければと思います。

この投稿でも、既存環境への適用を避けて新規の VCSA 6.7 u1 をデプロイします。

 

vCenter Server Appliance (VCSA) のデプロイ。

今回は、デプロイ手順を簡略化するため CLI を利用します。

vcsa-deploy.exe での CLI デプロイは、ちゃんとサポートされる方法です。

VCSA 6.7 を CLI デプロイしてみる。(embedded-PSC x2 の Enhanced Linked Mode)

 

デプロイ環境について。

 

VCSA は、この投稿時点で最新のバージョンを利用します。

  • バージョン: VMware vCenter Server 6.7 Update 1 ビルド 10244745
  • インストーラ: VMware-VCSA-all-6.7.0-10244745.iso

 

デプロイ先として、ESXi 6.7 u1 環境はセットアップずみです。

  • ESXi インストールずみ。
  • VCSA の Tiny デプロイのスペック以上のマシンが必要。
    • CPU 2コア(スレッド)以上
    • メモリは最小 16GB程度(ESXi と VCSA の 10GB を搭載できる程度)
    • ディスク
  • データストア名、ポートグループ名はそのまま。
  • ネットワーク / DNS アドレスはデプロイ環境にあわせる。
  • ユーザ / パスワードは、いつものデモ用のもの。

 

CLI で指定するデプロイ設定のファイル(JSON のテキストファイル)は下記のようにしました。

 

lab-vcsa-67u1.json · GitHub

  • 今回のハックのために、SSH アクセスを有効化しています。
  • 正式には system_name で VCSA のアドレスで FQDN のホスト名を指定しますが、
    ラボでの DNS レコード省略のため IP アドレスににします。

{

    "__version": "2.13.0",

    "__comments": "deploy a VCSA with an embedded-PSC on an ESXi host.",

    "new_vcsa": {

        "esxi": {

            "hostname": "192.168.1.20",

            "username": "root",

            "password": "VMware1!",

            "deployment_network": "VM Network",

            "datastore": "datastore1"

        },

        "appliance": {

            "thin_disk_mode": true,

            "deployment_option": "tiny",

            "name": "lab-vcsa-67u1"

        },

        "network": {

            "ip_family": "ipv4",

            "mode": "static",

            "ip": "192.168.1.55",

            "dns_servers": [

                "192.168.1.101",

                "192.168.1.102"

            ],

            "prefix": "24",

            "gateway": "192.168.1.1",

            "system_name": "192.168.1.55"

        },

        "os": {

            "password": "VMware1!",

            "ntp_servers": [

                "192.168.1.101",

                "192.168.1.102"

            ],

            "ssh_enable": true

        },

        "sso": {

            "password": "VMware1!",

            "domain_name": "vsphere.local"

        }

    },

    "ceip": {

        "settings": {

            "ceip_enabled": false

        }

    }

}

 

VCSA デプロイの実施。

それでは、Windows クライアントからデプロイします。

VCSA のインストーラは F: ドライブにマウントしています。

 

事前チェック

※ lab-vcsa-67u1.json はファイルを配置したパスを指定します。

PS> cd F:/vcsa-cli-installer/win32/

PS> ./vcsa-deploy.exe install --no-esx-ssl-verify --accept-eula --precheck-only ~/lab-vcsa-67u1.json

 

デプロイ実行

PS> ./vcsa-deploy.exe install --no-esx-ssl-verify --accept-eula ~/lab-vcsa-67u1.json

 

デプロイ処理が完了すると、HTML5 の

vSphere Client にアクセスできるようになります。

vcsa-html5-hack-01.png

 

HTML5 Client(vSphere Client)の色を変更してみる。

※ここからは非サポートの方法です。

 

今回は、スクリプトを用意してみました。

Add custom color to vSphere HTML5 UI Header/Footer in vSphere 6.7 Update 1 · GitHub

 

NotSupported_H5ClientHacks-Xmas.sh ファイルの内容

  • 元ファイルを、いちおうバックアップ。
  • ファイルの置き換えからサービス再起動まで実行。
  • 色がクリスマス風。

NEW_HEADER_HEX_COLOR=006400

NEW_BOTTOM_HEX_COLOR=8b0000

BACKUP_FILE=/usr/lib/vmware-vsphere-ui/plugin-packages/root-app/plugins/h5ngc.war.bak

if [ ! -e ${BACKUP_FILE} ]; then

  cp /usr/lib/vmware-vsphere-ui/plugin-packages/root-app/plugins/h5ngc.war ${BACKUP_FILE}

fi

mkdir -p /root/work

cd /root/work

cp /usr/lib/vmware-vsphere-ui/plugin-packages/root-app/plugins/h5ngc.war .

unzip h5ngc.war

rm -f h5ngc.war

cat << EOF >> resources/css/NotSupported_H5ClientHacks.css

.main-nav HEADER{

  background-color:#${NEW_HEADER_HEX_COLOR} !important; }

bottom-panel toggle-splitter {

  background: #${NEW_BOTTOM_HEX_COLOR} !important; }

EOF

sed -i '/--%>/a \

\n   <link href="resources/css/NotSupported_H5ClientHacks.css" rel="stylesheet"/>' WEB-INF/views/index.jsp

zip -r /root/h5ngc.war config  error.jsp  locales  META-INF  notfound.jsp  plugin.xml  resources  webconsole.html  WEB-INF

cd /root

rm -rf /root/work

cp /root/h5ngc.war /usr/lib/vmware-vsphere-ui/plugin-packages/root-app/plugins/

service-control --stop vsphere-ui; service-control --start vsphere-ui

 

VCSA に SSH でログインして、shell を起動します。

[gowatana@infra-jbox-01 ~]$ ssh root@192.168.1.55

 

VMware vCenter Server Appliance 6.7.0.20000

 

Type: vCenter Server with an embedded Platform Services Controller

 

root@192.168.1.55's password:

Last login: Sat Dec  1 03:46:41 2018 from 192.168.1.103

Connected to service

 

    * List APIs: "help api list"

    * List Plugins: "help pi list"

    * Launch BASH: "shell"

 

Command> shell

Shell access is granted to root

root@photon-machine [ ~ ]#

 

スクリプトをダウンロードして、実行します。

root@photon-machine [ ~ ]# curl -O https://gist.githubusercontent.com/gowatana/a82d8038c7994e317484d747e8edf461/raw/NotSupported_H5ClientHacks-Xmas.sh

root@photon-machine [ ~ ]# bash ./NotSupported_H5ClientHacks-Xmas.sh

 

もしくは、ダウンロード~実行をまとめることもできます。

root@photon-machine [ ~ ]# curl https://gist.githubusercontent.com/gowatana/a82d8038c7994e317484d747e8edf461/raw/NotSupported_H5ClientHacks-Xmas.sh | bash

 

サービスの再起動をまって HTML5 の vSphere Client にアクセスすると、

クリスマス風になります。

vcsa-html5-hack-02.png

 

元に戻す場合は、下記のようにバックアップ ファイルをリストアして、

サービスを再起動します。

root@photon-machine [ ~ ]# cp /usr/lib/vmware-vsphere-ui/plugin-packages/root-app/plugins/h5ngc.war.bak /usr/lib/vmware-vsphere-ui/plugin-packages/root-app/plugins/h5ngc.war

root@photon-machine [ ~ ]# service-control --stop vsphere-ui; service-control --start vsphere-ui

 

以上、vSphere Client をクリスマスカラーにしてみる話でした。

vE アドベントカレンダー 2日目は kmassue さんの予定です。よろしくお願いします。

ここまで、PowerCLI を利用したネステッド vSAN 環境セットアップの工夫を紹介してきました。

今回は、ここまでのコマンドラインを利用したスクリプトによるデプロイ簡素化についてです。

 

これまでの話については下記をどうぞ。

図解 ネステッド vSAN ラボ。

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

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

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

 

今回のサンプルスクリプトは、下記に配置しました。

GitHub - gowatana/deploy-1box-vsan

 

vSAN 環境の初期化。

まず、ここまでで下記のような vSAN 環境をセットアップしてあります。

vsan-1box-5-1.png

 

はじめに、再度デプロイをためすために、一度環境を初期化します。

前回に引き続き、PowerCLI は Connect-VIServer で vCenter に接続したままの状態です。

 

今回の vSAN クラスタ名と、ESXi VM の名前は下記です。

$cluster_name = "vSAN-Cluster"

$vm_name = "vm-esxi-??"

 

vSAN クラスタにある ESXi をすべて削除して、クラスタも削除します。

今回はラボを初期化してしまうので、ESXi はメンテナンスモードなどにはせず

切断 → インベントリから削除 としています。

$cluster = Get-Cluster $cluster_name

$cluster | Get-VMHost | Set-VMHost -State Disconnected -Confirm:$false

$cluster | Get-VMHost | Remove-VMHost -Confirm:$false

$cluster | Remove-Cluster -Confirm:$false

 

ESXi VM も削除します。

Get-VM $vm_name | Stop-VM -Confirm:$false

Get-VM $vm_name | Remove-VM -DeletePermanently -Confirm:$false

 

これで、vCenter のインベントリから、ネステッド vSAN 環境が削除されます。

vsan-1box-5-2.png

 

vSAN 環境のデプロイ。(スクリプト簡素化版)

それでは、スクリプトでデプロイしてみます。

 

設定情報については、できるだけスクリプトから分離したいので

下記のようなファイルを作成しました。

 

config_vSAN-Cluster-01.ps1

# Lab Global Setting.

$base_vc_address = "192.168.1.30"

$base_vc_user = "administrator@vsphere.local"

$base_vc_pass = "VMware1!"

 

 

 

$nest_vc_address = "192.168.1.30"

$nest_vc_user = "administrator@vsphere.local"

$nest_vc_pass = "VMware1!"

 

$domain = "go.lab.jp"

$hv_ip_prefix_vmk0 = "192.168.1."

$hv_subnetmask = "255.255.255.0" # /24

$hv_gw = "192.168.1.1"

$dns_1 = "192.168.1.101"

$dns_2 = "192.168.1.102"

$hv_user = "root"

$hv_pass = "VMware1!"

 

# Base ESXi Setting

$template_vm_name = "vm-esxi-template-01"

$hv_name = "192.168.1.20"

$base_hv_name = "192.168.1.20"

 

# Cluster setting

$vm_num_start = 1

$vm_num_end = 3

$cluster_name = "vSAN-Cluster-01"

 

# vSAN Disk setting

$vsan_cache_dev = "mpx.vmhba0:C0:T1:L0"

$vsan_capacity_dev = "mpx.vmhba0:C0:T2:L0", "mpx.vmhba0:C0:T3:L0"

 

# VM / ESXi List

$nest_hv_hostname_prefix = "esxi-"

$vm_name_prefix = "vm-esxi-"

 

$vm_name_list = $vm_num_start..$vm_num_end | % {

    $i = $_

    $vm_name_prefix + $i.toString("00")

}

 

$nest_hv_hostname_list = $vm_num_start..$vm_num_end | % {

    $i = $_

    $nest_hv_hostname_prefix + $i.toString("00")

}

 

$hv_ip_vmk0_list = $vm_num_start..$vm_num_end | % {

    $i = $_

    $hv_ip_prefix_vmk0 + (30 + $i).ToString()

}

 

$vc_hv_name_list = $vm_num_start..$vm_num_end | % {

    $i = $_

    $hv_ip_prefix_vmk0 + (30 + $i).ToString()

}

 

下記のようにコマンドライン1行でデプロイできます。

(ただし、今回の対象は ESXi VM 作成以降の部分です)

PowerCLI> ./setup_vSAN-Cluster_AllFlash.ps1 ./config_vSAN-Cluster-01.ps1

 

スクリプトからの出力表示は粗いままですが・・・

vsan-1box-5-3.png

 

下記のように、前回までにデプロイした vSAN と同様の環境がセットアップできます。

vsan-1box-5-4.png

 

今回は SSD 上でのネステッド環境ですが、

ハイブリッド構成にみせかけてネステッド vSAN をセットアップすることもできます。

PowerCLI> ./setup_vSAN-Cluster_Hybrid.ps1 ./config_vSAN-Cluster-02.ps1

vsan-1box-5-5.png

 

vSAN 環境の初期化。(スクリプト簡素化版)

冒頭に実施した vSAN 環境の初期化もスクリプト化しておくと、

下記のように再構築も簡素化できます。

PowerCLI> ./destroy_vSAN-Cluster.ps1 ./config_vSAN-Cluster-01.ps1

PowerCLI> ./destroy_vSAN-Cluster.ps1 ./config_vSAN-Cluster-02.ps1

 

以上、ネステッド vSAN 環境構築の簡素化についてでした。

ひきつづき、ネステッド vSAN 環境セットアップの工夫を紹介します。

今回は、vSAN クラスタのセットアップです。PowerCLI も利用していきます。

 

これまでの話は下記をどうぞ。

図解 ネステッド vSAN ラボ。

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

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

 

前回までの投稿にて、起動されたネステッド ESXi が用意されているので、

ここからは、クラスタの作成、ESXi の登録、クラスタでの vSAN 有効化

といったことを進めていきます。

1box-vsan-13.png

3-1. クラスタの作成。

vCenter のインベントリに、クラスタ「vSAN-Cluster」を作成します。

PowerCLI は、以前の投稿にて vCenter に接続したままの状態です。

この時点では、まだ vSAN は有効化していません。

PowerCLI> Get-Datacenter LAB-DC | New-Cluster -Name vSAN-Cluster

 

3台のネステッド ESXi (Nest-ESXi)を登録します。

  • PowerCLI の Add-VMHost コマンドを利用。
  • ESXi は、IP アドレスのまま(192.168.1.31 ~ 192.168.1.33)でインベントリ登録。
  • ESXi VM は 1つのテンプレート VM からクローンしているため、
    ID 重複によるエラーをさけたいのでローカルデータストア(datastore1)は ESXi から除去。
  • データストア削除(Remove-Datastore)でエラーになってしまいますが、
    データストアは外せるので、今回はエラーを無視しています。

 

PowerCLI のプロンプトに投入するコマンドラインは、下記のようにします。

"192.168.1.31","192.168.1.32","192.168.1.33" | %{

    $hv_name = $_

    Add-VMHost -Name $hv_name -Location (Get-Cluster vSAN-Cluster) -User root -Password VMware1! -Force

    Get-VMHost $hv_name | Remove-Datastore -Datastore "datastore*" -Confirm:$false -ErrorAction:Ignore

}

 

Nest-ESXi の VMkernel ポートで vSAN トラフィックを有効にします。

設定対象はクラスタ「vSAN-Cluster」配下の、全ホストの vmk0 です。

本番環境では、vSAN トラフィックは( vmk1 などに)分離することが多いはずですが、

ラボ用途なので今回はシンプルに vmk0 に相乗りさせています。

PowerCLI> Get-Cluster vSAN-Cluster | Get-VMHost | Get-VMHostNetworkAdapter -Name vmk0 | Set-VMHostNetworkAdapter -VsanTrafficEnabled:$true -Confirm:$false

 

3-2. vSAN クラスタのセットアップ。

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

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

 

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

「ScsiLun」などから、Nest-ESXi の認識しているデバイス名を確認しておきます。

容量や VMDK の接続順などから、デバイス名を特定できます。

このデバイス名は、Nest-ESXi の vSCSI / VMDK 構成が同じであれば、必ず同じものになります。

PowerCLI> Get-Cluster vSAN-Cluster | Get-VMHost | Get-VMHostDisk | select VMHost,ScsiLun,TotalSectors | Sort-Object VMHost,ScsiLun

 

VMHost       ScsiLun             TotalSectors

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

192.168.1.31 mpx.vmhba0:C0:T0:L0     33554432

192.168.1.31 mpx.vmhba0:C0:T1:L0     41943040

192.168.1.31 mpx.vmhba0:C0:T2:L0    104857600

192.168.1.31 mpx.vmhba0:C0:T3:L0    104857600

192.168.1.32 mpx.vmhba0:C0:T0:L0     33554432

192.168.1.32 mpx.vmhba0:C0:T1:L0     41943040

192.168.1.32 mpx.vmhba0:C0:T2:L0    104857600

192.168.1.32 mpx.vmhba0:C0:T3:L0    104857600

192.168.1.33 mpx.vmhba0:C0:T0:L0     33554432

192.168.1.33 mpx.vmhba0:C0:T1:L0     41943040

192.168.1.33 mpx.vmhba0:C0:T2:L0    104857600

192.168.1.33 mpx.vmhba0:C0:T3:L0    104857600

 

 

各ホストでディスクグループを作成します。

PowerCLI> Get-Cluster vSAN-Cluster | Get-VMHost | New-VsanDiskGroup -SsdCanonicalName mpx.vmhba0:C0:T1:L0 -DataDiskCanonicalName mpx.vmhba0:C0:T2:L0,mpx.vmhba0:C0:T3:L0

 

ディスクグループ作成が完了すると、その分の

vSAN データストアの容量(CapacityGB)も増加します。

PowerCLI> Get-Cluster vSAN-Cluster | Get-VsanSpaceUsage

 

Cluster              FreeSpaceGB     CapacityGB

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

vSAN-Cluster         295.945         299.953

 

 

これで、vSAN データストアが構成されて、

そこに VM を作成したりできるようになりました。

ネステッド環境上でのポートグループの作成やVM の作成などは、

基本的にネストであることを意識せずに実施します。

 

ちなみに、vSAN クラスタの PowerCLI でのセットアップについては、以前にも投稿しましたが、

こちらは少し前のものなので、現行のハンズオンラボ環境には未対応です・・・

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

 

以上、ネステッド vSAN の環境セットアップについての話でした。

 

まだ続きあり。

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

前回に続いて、ネステッド vSAN 環境セットアップの工夫を紹介します。

今回は、特にネスト特有の、物理マシンの ESXi と、ESXi VM の部分についてです。

ひきつづき PowerCLI も利用していきます。

 

これまでの話は下記をどうぞ。

図解 ネステッド vSAN ラボ。

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

 

ネステッド ハイパーバイザとなる ESXi VM は、下図のように

vCenter(VCSA)と横並びの VM として作成して、ネスト環境特有の設定をします。

今回は最初に、テンプレートにする ESXi VM を作成し、

それをクローンして 3台の ネステッド ESXi にします。

1box-vsan-12.png

2-1. ESXi VM を接続するポートグループの作成。

ESXi にデフォルトで作成される「VM Network」ポートグループは、

今回の構成ではネストではない VM で利用するものとします。

そこで、デフォルトで作成される仮想スイッチ「vSwitch0」に、

ESXi VM を接続する、ネスト環境むけのポートグループ

「Nested-Trunk-Network」を新規作成します。

 

このポートグループには、下記の設定をしています。

  • 無差別モード(プロミスキャスモード)の許可。
  • 「偽装転送」と「MAC アドレス変更」はデフォルト同様に「許可」。
  • VLAN ID 4095。

※ PowerCLI は前回の投稿で vCenter に接続したままの状態です。

PowerCLI> $pg_name = "Nested-Trunk-Network"

PowerCLI> $pg = Get-VMHost | Get-VirtualSwitch -Name vSwitch0 | New-VirtualPortGroup -Name $pg_name -VLanId 4095

PowerCLI> $pg | Get-SecurityPolicy | Set-SecurityPolicy -AllowPromiscuous:$true -ForgedTransmits:$true -MacChanges:$true

 

2-2. ESXi VM の作成。

ESXi をインストールする VM を作成します。

これは、あとで複数台の ESXi をクローンするための、VM テンプレートとして利用する想定です。

 

今回は、下記のような PowerCLI スクリプトで VM を作成します。

末尾の 4行では「ハードウェア アシストによる仮想化をゲスト OS に公開」にあたる

NestedHVEnabled を有効にしています。

また、vNIC は 最低限である 1つだけ作成しています。

 

create-esxi-vm.ps1

$vm_name = "vm-esxi-template-01"

$hv_name = "192.168.1.20"

 

$guest_id = "vmkernel65Guest"

$num_cpu = 2

$memory_gb = 6

$ds_name = "datastore1"

$vmdk_gb = 16

$pg_name = "Nested-Trunk-Network"

 

$vm = New-VM -Name $vm_name -VMHost $hv_name `

    -GuestId $guest_id `

    -NumCpu $num_cpu -CoresPerSocket $num_cpu `

    -MemoryGB $memory_gb `

    -DiskGB $vmdk_gb -Datastore $ds_name -StorageFormat Thin `

    -NetworkName $pg_name

 

$vm = Get-VM -Name $vm_name

$vm_config_spec = New-Object VMware.Vim.VirtualMachineConfigSpec

$vm_config_spec.NestedHVEnabled = $true

$vm.ExtensionData.ReconfigVM($vm_config_spec)

 

スクリプトは、vCenter に接続した状態で、下記のように実行します。

PowerCLI> .\create-esxi-vm.ps1

 

さまざまな vSAN を作成しやすいように、

VMDK の追加や ISO ファイルの接続はクローン後に実施します。

 

2-3. ESXi VM への ESXi インストールとクローン準備。

まず ESXi VM に、ESXi インストーラの ISO イメージファイルを接続してから起動し、

通常どおり ESXi をインストールします。

 

ESXi インストーラの ISO イメージファイルも、PowerCLIで VM に接続します。

ISO イメージファイルは、あらかじめ 物理マシン ESXi のデータストアに配置してあります。

※ESXi を Kickstart でインストールする場合は、この ISO イメージファイル接続は不要です。

PowerCLI> $iso_path = "[datastore1] iso/VMware-VMvisor-Installer-6.7.0.update01-10302608.x86_64.iso"

PowerCLI> Get-VM vm-esxi-?? | New-CDDrive -IsoPath $iso_path -StartConnected:$true

 

ESXi Shell を有効化して、vSphere Client の VM のコンソールからログインします。

この時点では、まだネットワーク設定は不要です。

 

下記の 2つの設定をします。

 

1) クローンによる MAC アドレス変更の対策として、

/Net/FollowHardwareMac を有効化します。

[root@localhost:~] esxcli system settings advanced set -o /Net/FollowHardwareMac -i 1

 

2) クローン後の ESXi VM 初回起動で UUID を再生成するために、

/etc/vmware/esx.conf ファイルから「/system/uuid」をいったん記載削除します。

※ これは vi などの編集でもよいです。

[root@localhost:~] sed -i "/uuid/d" /etc/vmware/esx.conf

 

設定後、ESXi VM をシャットダウンします。

クローン前に ESXi VM を起動した場合は、また /system/uuid を記載削除する必要があります。

 

また、VM テンプレートには、変換しても、しなくても大丈夫です。

 

2-4. ESXi VM のクローン。

ここまでに作成した VM「vm-esxi-template-01」から、3台の VM をクローンします。

  • PowerCLI は、vCenter に接続した状態で 物理マシン ESXi「192.168.1.20」上の VM をクローン。
  • 仮想マシン名は「vm-esxi-XX」とする。

PowerCLI> 1..3 | % {New-VM -VMHost 192.168.1.20 -StorageFormat Thin -VM "vm-esxi-template-01" -Name ("vm-esxi-" + $_.toString("00"))}

 

vSAN Disk として利用する VMDK を追加します。

今回は Cache 用に 20GB x 1、Capacity 用に 50GB x 2 を 各 ESXi に用意します。

PowerCLI> Get-VM vm-esxi-?? | New-HardDisk -SizeGB 20 -StorageFormat Thin

PowerCLI> Get-VM vm-esxi-?? | New-HardDisk -SizeGB 50 -StorageFormat Thin

PowerCLI> Get-VM vm-esxi-?? | New-HardDisk -SizeGB 50 -StorageFormat Thin

 

VMDK は下記のように作成されます。

PowerCLI> Get-VM vm-esxi-?? | Get-HardDisk | select CapacityGB,Parent,Name | Sort-Object Parent,Name

 

CapacityGB Parent     Name

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

        16 vm-esxi-01 Hard disk 1

        20 vm-esxi-01 Hard disk 2

        50 vm-esxi-01 Hard disk 3

        50 vm-esxi-01 Hard disk 4

        16 vm-esxi-02 Hard disk 1

        20 vm-esxi-02 Hard disk 2

        50 vm-esxi-02 Hard disk 3

        50 vm-esxi-02 Hard disk 4

        16 vm-esxi-03 Hard disk 1

        20 vm-esxi-03 Hard disk 2

        50 vm-esxi-03 Hard disk 3

        50 vm-esxi-03 Hard disk 4

 

 

ESXi VM をまとめてパワーオンします。

PowerCLI> Get-VM vm-esxi-?? | Start-VM

 

このあとの工程に備えて、ネステッド ESXi の VMware Tools が起動したことを確認しておきます。

PowerCLI> Get-VM vm-esxi-?? | select Name,PowerState,@{N="ToolsStatus";E={$_.Guest.ExtensionData.ToolsStatus}}

 

Name       PowerState ToolsStatus

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

vm-esxi-03  PoweredOn     toolsOk

vm-esxi-02  PoweredOn     toolsOk

vm-esxi-01  PoweredOn     toolsOk

 

 

2-5. ネステッド ESXi の設定。

ネステッド ESXi が起動したら、普通の ESXi と同様に

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

これは VM コンソール経由で DCUI や esxcli などで設定できます。

 

しかし、ESXi には標準で VMware Tools がインストールされており、

VM にインストールした場合は、vCenter 経由で(ゲスト OS としての)ESXiのコマンドが実行できます。

そして、それを PowerCLI 経由で実行することもできます。

 

そこで、下記の投稿にある PowerCLI のサンプルスクリプトを利用して、

3台の ESXi VM それぞれにむけて esxcli によるネットワーク設定をします。

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

 

1台目。

PowerCLI> ./invoke_nested-esxcli.ps1 -ESXiUser:root -ESXiPass:VMware1! -ESXiVM:vm-esxi-01 system hostname set --host esxi-01 --domain go-lab.jp

PowerCLI> ./invoke_nested-esxcli.ps1 -ESXiUser:root -ESXiPass:VMware1! -ESXiVM:vm-esxi-01 network ip interface ipv4 set --interface-name=vmk0 --type=static --ipv4=192.168.1.31 --netmask=255.255.255.0 --gateway=192.168.1.1

PowerCLI> ./invoke_nested-esxcli.ps1 -ESXiUser:root -ESXiPass:VMware1! -ESXiVM:vm-esxi-01 network ip dns server add --server=192.168.1.101

PowerCLI> ./invoke_nested-esxcli.ps1 -ESXiUser:root -ESXiPass:VMware1! -ESXiVM:vm-esxi-01 network ip dns server add --server=192.168.1.102

 

2台目。

PowerCLI> ./invoke_nested-esxcli.ps1 -ESXiUser:root -ESXiPass:VMware1! -ESXiVM:vm-esxi-02 system hostname set --host esxi-02 --domain go-lab.jp

PowerCLI> ./invoke_nested-esxcli.ps1 -ESXiUser:root -ESXiPass:VMware1! -ESXiVM:vm-esxi-02 network ip interface ipv4 set --interface-name=vmk0 --type=static --ipv4=192.168.1.32 --netmask=255.255.255.0 --gateway=192.168.1.1

PowerCLI> ./invoke_nested-esxcli.ps1 -ESXiUser:root -ESXiPass:VMware1! -ESXiVM:vm-esxi-02 network ip dns server add --server=192.168.1.101

PowerCLI> ./invoke_nested-esxcli.ps1 -ESXiUser:root -ESXiPass:VMware1! -ESXiVM:vm-esxi-02 network ip dns server add --server=192.168.1.102

 

3台目。

PowerCLI> ./invoke_nested-esxcli.ps1 -ESXiUser:root -ESXiPass:VMware1! -ESXiVM:vm-esxi-03 system hostname set --host esxi-03 --domain go-lab.jp

PowerCLI> ./invoke_nested-esxcli.ps1 -ESXiUser:root -ESXiPass:VMware1! -ESXiVM:vm-esxi-03 network ip interface ipv4 set --interface-name=vmk0 --type=static --ipv4=192.168.1.33 --netmask=255.255.255.0 --gateway=192.168.1.1

PowerCLI> ./invoke_nested-esxcli.ps1 -ESXiUser:root -ESXiPass:VMware1! -ESXiVM:vm-esxi-03 network ip dns server add --server=192.168.1.101

PowerCLI> ./invoke_nested-esxcli.ps1 -ESXiUser:root -ESXiPass:VMware1! -ESXiVM:vm-esxi-03 network ip dns server add --server=192.168.1.102

 

 

これで、ネステッド ESXi が 3台作成された状態になります。

あとは、vSAN クラスタのセットアップです。

 

つづく・・・

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

前回はネステッド vSAN のイメージ(下記)を紹介したので、

今回はセットアップ手順での工夫についての紹介です。

図解 ネステッド vSAN ラボ。

 

一般的には、ESXi の Host Client や vSphere Client / vSphere Web Client といった

GUI のツールを利用することが多いと思います。

しかし、検証環境は様々なバージョン / 構成でセットアップすることが多いはずなので、

ここでは、パラメータ記録や自動化をしやすいように PowerCLI などを積極的に利用します。

 

最初にネステッド vSAN 環境のベースとなる 物理マシンの ESXi と、vCenter Server を用意します。

1box-vsan-11a.png

 

1-1. 物理マシンへの ESXi のインストール。

物理マシンへの ESXi のインストールは、通常どおり ISO イメージから作成した CD ブートです。

マシンの管理ボードなどから ISO ファイルをマウントできる場合は、ISO イメージそのものから、

PXE サーバを用意している場合は、Kickstart でインストールすることができます。

 

一般的には、インストール方法にかかわらず ISO イメージでインストールしたうえで

オフラインバンドル(zip ファイル)のパッチを適用することになります。

今回は ESXi 6.7 U1 の ISO を利用していて、その後のパッチは(まだないので)適用していませんが、

あらかじめ下記のようにオフラインバンドルファイルから

ISO イメージファイルを作成しておくと、インストール直後にパッチ適用された状態になるので便利です。

ESXi のオフライン バンドルから ISO イメージ ファイルを作成してみる。

 

1-2. 物理マシンの設定。

今回、ESXi インストール直後に、下記の ESXi 設定変更のみ実施しておきます。

  • ネットワーク設定。(IP アドレス、サブネットマスク、デフォルトゲートウェイ)
  • 時刻あわせ。NTP を設定して確実に時刻同期をするか、Host Client や esxcli などで手動で設定変更します。
    • ESXi の都合上、UTC(JST マイナス9時間)で設定します。
      これは、VCSA のデプロイ時に時間がずれていると失敗してしまうためです。

 

データストア名や仮想スイッチ / ポートグループの構成は、

この時点ではデフォルトのままです。

これらの設定変更は、この ESXi を vCenter 管理下にしたあとで実施します。

 

1-3. VCSA のデプロイ。

vCenter Server Appliance(VCSA)をデプロイします。

VCSA は、何度もデプロイするような場合は vcsa-deploy による CLI インストール(下記のような)がおすすめです。

VCSA 6.7 を CLI デプロイしてみる。(embedded-PSC x2 の Enhanced Linked Mode)

 

vcsa-deploy コマンドのオプションと、インストールで利用する JSON ファイルは、

VCSA 6.7 以前 / 以降 のバージョンでパラメータが異なります。

ちなみに VCSA 6.5 形式の JSON ファイルは、VCSA 6.7 でも利用できました。

 

本番環境での VCSA のデプロイは、FQDN でのホスト名指定が事実上必須ですが、

ラボのとりまわしをよくするためにホスト名のかわりに IP アドレスを指定して

デプロイすることもあります。(DNS サーバへの vCenter アドレス登録を省略できるので)

 

ちなみに複数、同名の VCSA をデプロイすると、証明書のエラーにより

Chrome などのブラウザで vSphere Web Client / vSphere Client が

表示できなくなることがあります。

その場合は、以前の投稿にも記載しましたが・・・

VCSA 6.5 U1 を CLI デプロイしてみる。(vCenter + embedded-PSC)

下記の要領で解消できることもあります。

ちなみに、何度も同じ名前で vCenter をデプロイしていると Chrome / Microsoft Edge で

証明書のエラーになり HTML5 Client / vSphere Web Client にアクセスできなくなることがありますが、

その場合はデプロイした VCSA の CA 証明書を(Firefox などアクセスできるブラウザで何とかダウンロードして)

インストールするとアクセス可能になります。

※その場合、証明書は「https://vCenterのアドレス/certs/download.zip」からダウンロードできます。

 

1-4. VCSA への物理マシン ESXi の登録。

デプロイした vCenter のインベントリにクラスタを作成して、物理マシンの ESXi を登録します。

せっかくなので PowerCLI 11 を利用します。

 

まず、PowerCLI で ESXi に接続します。

今回の vCenter のアドレスは「192.168.1.30」です。

管理ユーザなどのパスワードは、あえてデモ用としてよく知られているものを利用しています。

vCenter の SSL 証明書を入れ替えていないので、エラー回避のため「-Force」が必要です。

PowerCLI> Connect-VIServer 192.168.1.30 -User administrator@vsphere.local -Password VMware1! -Force

 

vCenter インベントリに、データセンター「LAB-DC」を作成します。

PowerCLI> Get-Folder -Type Datacenter | New-Datacenter LAB-DC

 

物理マシン ESXi を登録するクラスタ「MGMT-Cluster」を作成します。

ここではクラスタは必須ではないですが、せっかくなのでそれっぽく作成しています。

PowerCLI> Get-Datacenter LAB-DC | New-Cluster MGMT-Cluster

 

クラスタ「MGMT-Cluster」に、物理マシン ESXi「192.168.1.20」を登録します。

ここでも SSL エラー回避のため「-Force」が必要です。

PowerCLI> Get-Cluster MGMT-Cluster | Add-VMHost -Name 192.168.1.20 -User root -Password VMware1! -Force

 

次は vCenter からの操作で、物理マシン ESXi のうえに

ネステッド ハイパーバイザむけの ESXi と VM の準備をします。

 

つづく。

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