Skip navigation

今月は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

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

 

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

ネステッド 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 で起動できないことがありえます。

 

今回はラック単位でのフォールト ドメインを構成しているので、VM のデータの可用性が担保されているはずです。

 

それでは、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 が起動できています。

 

また、今回は 3つのフォールト ドメイン構成でしたが、可用性の観点では

障害時もリビルドができるように 4つ以上のフォールト ドメインがあるとよいはずです。

Designing and Sizing vSAN Fault Domains

 

つづく。

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

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

 

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

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

 

昨日はこちら。

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

 

15日目は、2ノード vSAN を展開して、その監視ホストを

疑似的に vSAN から物理的に距離があるデータセンタに配置してみます。

 

vSAN-Cluster-20181215 クラスタ

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

 

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(vNIC#1)のネットワーク設定。

[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(vNIC#2)のネットワーク設定。

[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」にしておきます。

なお、今回の ip_forward の設定は一時的なもので、Linux OS を再起動すると無効に戻ります。

[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 コマンドを利用してネットワーク遅延を発生させます。

なお、今回は ens192(vNIC#1)に遅延設定をしていますが、

SSH 接続経路の NIC に遅延設定をいれると操作が遅くなるため、

環境によっては別方向の NIC(vNIC#2 である ens224 など)に遅延設定をしてもよいです。

 

設定変更まえの、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 までサポートされています。

Networking and Latency Requirements

 

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 も置いたりすることがあります。

 

つづく。

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

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

 

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

ネステッド 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 セットアップの自動化・省力化について。

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

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

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

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

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

 

たとえば、VMware Sample Exchange で多くのサンプル スクリプトを見つけることができます。

vSAN Samples - Samples - VMware {code}

 

PowerCLI スクリプトを作成する場合には、まずは手動のコマンドライン実行で

これから自動化したい作業をしてみるとよいと思います。

たとえば、2ノード vSAN の PowerCLI セットアップで利用するコマンドラインは

下記のような様子になります。(少し古い投稿ですが)

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

 

 

vSAN セットアップ後の確認の省力化について。

今回は、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 からでも、このテストを実行できます。

 

PowerCLI コマンドレットは、Cmdlet Reference などで探すことができます。

Online Documentation - Cmdlet Reference - VMware {code}

 

今回利用する Test-VsanVMCreation コマンドレットのリファレンスです。

Test-VsanVMCreation - PowerCLI System.Collections.Hashtable.ModuleName Help Reference

 

テスト対象の 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 で頻繁に実行するのは避けたほうがよいかなと思います。

 

つづく。

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

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

 

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

ネステッド 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ノード → 3ノード以上 vSAN の変更については、下記のドキュメントが参考になります。

Converting a 2 Node Cluster with WTS to a 3 Node Cluster

Convert a Stretched Cluster to a Standard vSAN Cluster

 

開始時点は 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 を一旦停止して、

すべての ESXi をメンテナンスモードにしておくほうが無難です。

 

ESXi のインストール手順によっては、追加ノードで 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 のスナップショットを取得しておくと

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

 

つづく。

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

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

 

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

ネステッド 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: 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 を割り当てないローカル仮想スイッチを作成するという方法もあります。

 

つづく。

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

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

 

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

ネステッド 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(監視ホスト)を配置

 

2ノード vSAN については、VMware の Storage Hub サイトのドキュメントが参考になります。

vSAN 2 Node Guide

 

2ノード vSAN クラスタの様子。

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 としては応用的な構成だと思うので、

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

 

つづく。

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

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

 

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

ネステッド 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ノード以上を停止させると、すぐに書き込みができなくなるはずです。

 

つづく。

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