今月は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-Cluster-20181203b クラスタ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

SSD / HDD マークの仕組み。

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

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

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

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

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

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

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

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

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

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

つづく。

今月は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のもの） は １つだけです。

vSAN-Cluster-20181205 クラスタ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

つづく。

     All of us need help at some point, and it’s only too common to reach out to others to ask for help. Before you do that, however, you need to understand some basic rules. These rules exist not only to maintain a sense of courtesy and respect, but to ultimately get you the best help possible. While most of this wisdom is applicable to any online technology forum, it is specifically geared to the VMware Technology Network (VMTN), VMware’s official online community.

     In the interest of brevity, this article has been intentionally kept short and sweet. These are only the most basic and essential of rules to keep in mind. It is not meant to be an exhaustive list (because you probably wouldn’t read it then). But please read all of these. All of them. Seriously.

     There are three major categories you need to understand and read. All rules can be grouped in one of these categories.

A. Having an Issue

     When a problem strikes and you get the itch to reach out for help, make sure you’ve done all these first.

B. Planning to Post

     Once you’ve exhausted the resources on your own in Having an Issue, you want to make a post. Prior to that, understand what you’re walking in to and have a basic sense of expectation. It’s easy to forget some of these points.

C. Posting

     Now that you have a level set of things, you want to create that post. Ensure you do all of these things correctly and you’ll almost certainly solve your problem.

A. Having an Issue

     1. Help yourself first. Always. This means conducting multiple, basic searches on Google in addition to the forum on which you intend to post. If a user can answer your question with a result from a Google search appearing in the first page, you have failed this step.

     2. Read the documentation. The term “RTFM” comes to mind. You need to read what has already been written on the product in question. This includes the release notes. You should never skip any of these two steps.

B. Planning to Post

     1. Do not post angry or with an attitude. If you’re heated or frustrated with your issue, wait a while and calm down. Do not take your anger out on a public forum. It does absolutely no good and only turns people away.

     2. Always read the community rules. Yes, those you agreed to uphold when you registered an account. Read and commit them all to memory.

     3. Keep in mind these things when asking others for help:

1. These are volunteers with professional lives.

2. They are spending their spare, personal time to help YOU. That is time that could have been spent with their own friends and family, or to advance their careers.

3. Their knowledge and expertise is worth hundreds or thousands of dollars in any other venue.

4. You are getting all of this completely for free. You are expected to spend your time and convenience in exchange.

5. The community members don’t owe you anything whatsoever. Assistance is provided on a best-effort basis but you’re entitled to nothing.

6. While some are, most community members are not VMware employees which means:

   1. They don’t know futures and couldn’t tell them to you even if they did know. Don’t ask when a version is being released or if support for X will be included.

   2. This is not an extension of your support and subscription (SnS) contract. If you’re dissatisfied with a response or don’t get one, you can always open an official SR with VMware. If you can’t or don’t want to pay, that isn’t the community’s fault.

C. Posting

     1. Make your thread title appropriate and descriptive. Members should have a decent idea of what you’re asking before reading it. Examples of bad thread titles include:

1. “Vmware”
2. “I need help!!!”
3. “Do not start”

     2. Thoroughly describe your situation. Don’t be a lazy poster as there’s no one people hate helping less than that. Include all product names, all versions, and all steps you performed to generate the result. Here are some examples of actual bad questions:

1. “All our VMs were powered off on weekend and why dont know when and why?”

2. “Suggest discovery tools for data center migration”

3. “how to install SRM”

4. “I need to be able to enable the option to edit hot. vMware vSphere 6.5 does not have the option.”

5. “hello can someone help me with a kickstart script that will install esxi and configure a static ip address on vlan x for mgmt i would also like to add a second uplink to my vswitch and add a new portgroup for virtual machine traffic on vlan y”

6. “Hello Expert, please help to resolve this problem <screenshot>”

     Each of these examples is a violation of rules discussed earlier. If you aren’t sure why these are bad questions, start at the top and read again.

     3. Screenshots help immensely. If in doubt, post some screenshots anyway. VMTN allows pasting them directly in the body, making it extremely easy. But please don’t be an idiot by taking a picture of your filthy monitor with your camera phone (crashes excluded). If you don’t know how to take a proper screenshot, see Having an Issue and learn. Every OS has free screenshot tools built-in. Learn how to use them.

     4. Don’t ask for things on a silver platter. Asking for assistance is fine. Asking for someone to hand over bespoke or custom work to you is not. This includes scripts and custom documentation. Online forum communities are not places where you go to get your butt wiped.

     5. Attach logs. If you don’t know where they are or how to do that, see Having an Issue.

     6. Be responsive in your thread. If you care less about solving your own problem than the community members do, don’t expect them to go out of their way to help you.

     7. Why do you want to do this thing? Use case matters, because very often what you think you want to do shouldn’t be done that way. The community might have alternatives that work better for you. You never know.

     8. English may be a second language. People understand that you may not be an expert in English and that it’s hard. However, just because you haven’t mastered English doesn’t release you from attempting to help yourself first or providing enough information in your post.

To sum up these rules and reminders, let me distill it into just a few short sentences.

Show the community you're serious about helping yourself. You do this demonstrating most of these points: You searched, you read, you attempted to help yourself. When that failed, you thoroughly described your problem and provided ample details for others to take on your case. After getting responses, you responded in a timely fashion and were cordial, expressing appreciation for being helped. If you can follow this pattern, you will have the absolute best chance of getting your issue resolved.

Additional Links

https://communities.vmware.com/docs/DOC-1070

A good overall “how to” guide for asking and answering questions on VMTN. Focuses on the VMware Fusion product, but still good.

http://www.catb.org/esr/faqs/smart-questions.html
Probably the single-best FAQ for how to ask on technology message boards. Once you’ve mastered the rules in this short guide, read this FAQ to become a posting legend.

今月は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 ディスクグループが未作成の状態です。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

このように、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-06

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

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

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

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

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

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

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

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

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

「7」となっています。

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

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

実験1。

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

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

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

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

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

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

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

実験2。

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

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

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

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

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

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

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

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

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

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

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

つづく。

今月は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 には、仮想ディスクのコンポーネントごとの最大容量が設定されています。

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

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

このパラメータについては、下記の 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-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つのフォールト ドメインが存在することになります。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ネステッド ESXi による、疑似的なオールフラッシュ 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 の仮想マシン ストレージ ポリシーを作成します。

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

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

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

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

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

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

パワーオフ。

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

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

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

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

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

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

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

つづく。

Dear readers

this is the second blog of a series related to NSX-T. This second coverage provide you relevant information required to better understand the implication of a centralized services in NSX-T. In the first blog where I have provided you an introduction of the lab setup, this second blog will now discuss the impact when you add a Tier-1 Edge Firewall for the tenant BLUE. The diagram below shows the logical representation of the lab setup with the Edge Firewall attached to the Tier-1 uplink interface of the Logical Router for tenant BLUE.

For this blog I have selected to add an Edge Firewall for a Tier-1 Logical Router, but I could have also selected a Load Balancer, VPN service or NAT service. The implication to the "internal" NSX-T networking are similar. However, please keep in mind, not all NSX-T centralized services are supported at the Tier-1 level (as example VPN) or at Tier-0 (as example Load Balancer) with NSX-T 2.3 and not all services (as example DHCP or Metadata Proxy) will instantiate a Service Router.

Before I move forward and try to explain what is happen under the hood when you enable an Edge Firewall, I would like to update you with some additional information to the diagram below.

I am sure you are already familiar with this diagram above, as we have talked about the same in my first blog. Each of the four Transport Nodes (TN) has two tenants Tier-1 Logical Routers instantiated. Inside of each Transport Node there are two Logical Switches with VNI 17295 and 17296 between the Tier-1 tenant DR and Tier-0 DR used. These two automatically instantiated (sometimes referred as auto-plumbing) transit overlay Logical Switches have got subnets 100.64.144.18/31 and 100.64.144.20/31 automatic assigned. Internal filtering avoids duplicate IP address challenges;  in the same way as NSX-T is doing already for gateways IP (.254) the Logical Switches 17289 and 17294 where the VMs are attached. Each of this Tier-1 to Tier-0 transit Logical Switch (17295 and 17296) could be showed as linked together in the diagram, but as internal filtering takes place, this is for the moment irrelevant.

The intra Tier-0 Logical Switch with the VNI 17292 is used to forward traffic between the Tier-0 DRs and towards northbound via the Service Router (SR). This Logical Switch 17292 has again an automatic assigned IP subnet (169.254.0.0/28). Each Tier-0 DR has assigned the same IP address (.1), but the two Service Routers use different IPs (.2 and .3), otherwise the Tier-0 DR would not be able to forward based on equal cost with two different next hops.

Before the network administrator is able to configure an Edge Firewall for tenant BLUE at the Tier-1 level, he has to assign and edge-cluster to the Tier-1 Logical Router along the edge-cluster members. This is shown in the diagram below.

Please be aware, as soon as you assign an edge-cluster to a Tier-1 Logical Router a Service Router is automatically instantiated, independent of the Edge Firewall.

These two new Service Routers are running on the edge-nodes and they are in active/standby mode. Please see in the next diagram below.

The configuration of the tenant BLUE Edge Firewall itself is shown in the next diagram. Here we use for this lab the default firewall policy.

This simple configuration step with adding the two edge-nodes to the Tier-1 Logical Router for tenant BLUE will cause that NSX-T "re-organize" the internal auto-plumbing network. To understand what is happening under the hood, I have divided these internal network changes into four steps instead showing only the final result.

In step 1, NSX-T will internally disconnect the Tier-0 DR to Tier-1 DR for the BLUE tenant, as the northbound traffic needs to be redirected to the two edge-nodes, where the Tier-1 Service Routers are running. The internal Logical Switch with VNI 17295 is now explicit linked together between the four Transport Nodes (TN).

In step 2, NSX-T automatically instantiate on each edge-node a new Service Router at Tier-1 level for the tenant BLUE with an Edge Firewall. The Service Router are active/standby mode. In this example, the Service Router running on the Transport Node EN1-TN is active, where the Service Router running on EN2-TN is standby. The Tier-1 Service Router uplink interface with the IP address 100.64.144.19 is either UP or DOWN.

In step 3, NSX-T connects the Tier-1 Service Router and the Distributed Router for the BLUE tenant together. For this connection is a new Logical Switch with VNI 17288 added. Again, the Service Router running on EN1-TN has the active interface with the IP address 169.254.0.2 up and the Service Router on EN2-TN is down. This ensure, that only the active Service Router can forward traffic.

In the final step 4, NSX-T extends the Logical Switch with VNI 17288 to the two compute Transport Nodes ESX70A and ESX71A. This extension is required to route traffic from vm1 as example on the local host before the traffic is forwarded to the Edge Transport Nodes. NSX-T adds finally the required static routing between the different Distributed and Service Routers. NSX-T does all these steps under the hood automatically.

The next diagram below shows a traffic flow between vm1 and vm3. The traffic sourced from vm1 will first hit the local DR in the BLUE tenant on ESX70A-TN. The traffic now needs to be forwarded to the active Tier-1 Service Router (SR) with the Edge Firewall running on Edge Transport Node EN1-TN. The traffic reach then the Tier-0 DR on EN1-TN and then is the traffic forwarded to the RED Tier-1 DR and finally arrives at vm3. The return traffic will hit first the local DR in the RED tenant on ESX71A-TN before the traffic reach the Tier-0 DR on the same host. The next hop is the BLUE Tier-1 Service Router (SR). The Edge Firewall inspects the return traffic and forwards the traffic locally the BLUE Tier-1 DR before finally the traffic arrives back at vm1. The majority of the traffic is handled locally on the EN1-TN. The used bandwidth between the physically hosts and therefore the GENEVE encapsulated traffic is the same as without the Edge Firewall. But as everybody could imagine an edge-node which might hosts multiple Edge Firewalls for multiple tenants or any other centralized services should be designed accordingly.

Hope you had a little bit fun reading these two blogs. Feel free to share this blog!

Lab Software Details:

NSX-T: 2.3.0.0

vSphere: 6.5.0 Update 1 Build 5969303

vCenter:  6.5 Update 1d Build 2143838

Version 1.0 - 10.12.2018

今月は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 Witness アプライアンスをデプロイして、監視（Witness）ホストにしています。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

つづく。

vEXPERT 2018の山辺です。

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

（vExperts Advent Calendar 2018）

仮想化は知ってるけどGPUとは縁が無かった（少なかった）方は多いと思います。今回、この記事では、主にそういった方々を対象に、VMware vSphereを含む仮想環境上で動作する仮想マシンでもGPUの機能を享受できる、NVIDIA仮想GPUソリューションに関して、このソリューションが必要される背景と、その中身について、以下の章立てで、紹介したいと思います。（vGPU入門の位置づけ）

・GPUとは（実は身近なGPU）

・Windows10 VDIでGPUが必要とされる理由

・NVIDIAの仮想GPUソリューション

　（VMware Horizonといっしょに使うと幸せになれますよ、という話）

◆まえがき：GPUとは（実は身近なGPU）

「GPU？？なにそれ？つおい？」っていう方がいないことを期待しつつ、念のため、Wikiさんを引用させて頂くと、【Graphics Processing Unit（グラフィックス プロセッシング ユニット、略してGPU）は、コンピュータゲームに代表されるリアルタイム画像処理に特化した演算装置ないしプロセッサである。】と出ています。- Wikipedia: Graphics Processing Unit - Wikipedia

なんだか、とても強いそうです。いや、GPUを使ってる人は、本当に強いんです！

（分かりづらいけど、↓PC↓の中で緑に光るカッコいいパーツがGEFORCEっていうGPU！）

この紹介だけだと、「ほぅ。じゃ、おれは関係ないや」と一刀両断にされてしまいそうですね。確かに、GPUは、ゲーミングの世界だったり、CG、デザイン、CADのようなグラフィックプロフェッショナルの世界を支えている、というのは現在進行形の事実。ただ、その事実だけを見て、その世界の住人だけしか幸せになれないソリューションだと決めつけるのは大間違いだし、何より、もったいない！GPUは実は非常に身近なデバイス。今、そこらで売っているパソコンには、ほぼ全てGPUが搭載されているし、今、この記事を読んでいる、あなたのパソコンにも、相当高い確率でGPUは搭載されているはず。もう少し具体的な情報を添えさせて頂くと、インテル社のSandy Bridge世代のCore iシリーズのCPUには、画像出力専用回路としてGPUが統合されてます。つまり、GPUを選んで買ってなくても、気付かずに、GPUを使っているわけです。

仮想化界隈だと、Nehalem世代のXeonの登場により、仮想環境の集約率向上を記憶している人が多いのでは、と想像しますが、そのNehalem世代の次の世代がSandy Bridge世代ですね。（懐かしい）

と言うわけで、GPUがとても身近なもので、誰もが、GPU搭載のパソコンを使う時代になった、というのは、ご理解頂けたと思います！

ここで合わせて伝えたい情報があります。それは、「GPUがある環境を前提に、世の中のOSやアプリケーションはデザインされている（され始めている）」ということです。そして、その代表が、マイクロソフトさんのWindows10であり、皆様のビジネスを支えるOfficeアプリケーションやSkypeのようなWeb会議ソリューションです。これらのOSやアプリケーションが快適に動作し、皆様の日々のお仕事がテキパキ捗るのは、GPUのおかげでもあるのです！（もちろん、GPUだけでは何も出来ません）

◆Windows10 VDIでGPUが必要とされる理由

Windows10は、GPU標準時代のOSだという主旨の説明をしましたが、ワークスペース分析のリーディングカンパニーであるレイクサイドソフトウェア社が発行しているホワイトペーパーで、Windows 7とWindows 10におけるグラフィック性能の違いが、数値で出ていますので、ぜひ、ご一読頂きたいと思います。

（レイクサイドさん、本稿執筆のご協力、ありがとうございます！）

　◆補足情報（レイクサイドソフトウェア社ホワイトペーパー）

　　ワークスペース分析のリーディングカンパニーであるレイクサイドソフトウェア社が発行しているホワイトペーパーの中で、
　　Windows 7とWindows 10におけるグラフィック性能の違いが、数値で出ています。

　　・レイクサイドソフトウェア︓ホワイトペーパー

　　　GPU アクセラレーションを活⽤したユーザーエクスペリエンスの向上（Windows 10 の環境と Windows 7 の環境を対象とした⽐較分析）

　　　https://www.lakesidesoftware.com/jp/resources/white-papers/elevating-user-experience-through-gpu-acceleration

このホワイトペーパーを参考に、視覚的に分かりやすく棒グラフにすると以下のような感じになります。

　（下図：Windows 7とWindows 10におけるグラフィック性能の違い）

Windows7時代に比べ、Windows10時代は、OSもアプリケーションも、GPUパワーを活用して快適に動作するようになってます。このWindows10とアプリケーションを展開する仮想デスクトップ(VDI)環境に、もしGPUを搭載しないと、PCなら当たり前の必要なピースが欠けた状態を敢えて作ってるに等しく、応答性や操作性の悪い、非常に残念な環境となってしまいます。遅くても我慢して使ればいいじゃん、という声もあるかもしれませんが、GPUの無い環境では、GPUが処理するべき処理がCPUに襲い掛かります。結果、異常とも言えるCPU超高負荷状態が発生し、仮想マシンが落ちる、ESXホストが落ちる、という悪夢が現実に起きています。それを使うユーザーの立場としては、「こんな環境で仕事しろって言うの？」という受け入れがたい環境になってしまいます。（せっかく、たくさん投資して、VDIを導入したのに…）

この問題を回避するには、【VDIでもGPUを使う】ことが有効な手段です。そして、それが、NVIDIAが提供する【仮想GPUソリューション NVIDIA GRID】です。次の章で、その中身について、説明したいと思います。

◆NVIDIA仮想GPUソリューション

NVIDIAが提供している仮想GPUソリューションは、ひと言(?)で書くと、【物理GPUを、仮想化技術で複数の仮想GPUリソースに分割し、VMware等の環境上で稼働する仮想マシンにGPUパワーを付加するテクノロジー】です。元々、このテクノロジーは、従来、VDI環境では利用できないとされた、3D-CAD、CAE、CG制作などのグラフィックスアプリケーションを、VDI環境で利用できるようにするために、進化したもので、今では、たくさんの企業で活用されています。

　◆補足情報（NVIDIA 仮想GPUソリューション 成功事例）

　　たくさんの成功事例が紹介されてます。

　　https://www.nvidia.co.jp/object/grid-enterprise-resources-jp.html

GPUが付加されたVDIサーバーの構成は下図になります。通常のVDIには無いピースが黄緑色の部分です。VDIサーバーのハードウェアに物理GPUが搭載され、Hypervisor層で複数のvGPUに分割され、そのvGPUは、パソコンのGPUと同じように、各仮想マシンのGPUデバイスとしてアタッチされ、ネイティブなGPUのように動作します（グラフィックコマンドがそのまま届く）。

このようなGPU搭載の環境にすることで、前章で説明したWindows10であっても、GPUが処理すべきものがvGPU経由で物理GPUに流れますので、CPU負荷の低い、快適なVDI環境となります。VDIでのGPU有無の違いが、とても分かりやすい動画がYouTubeに公開されてますので、是非ご覧ください。（アプリの動作のスムーズさとタスクマネージャーのCPU負荷の違いを要チェックです）

　◆Windows 10 VDI with NVIDIA GRID vPC

過去のVDIでは、１サーバーあたりのメモリ搭載量のボトルネックや、ディスクのIOPSのボトルネックにより、集約率の向上が難しかった時代がありました。ひとつのボトルネックを解消すると、新たなボトルネックを生みますが、そのたびに、その壁を破る新しいテクノロジーが登場し、よりコストパフォーマンスの良い、より快適なVDI環境が実現されてきました。現在のWindows10時代のVDIでは、グラフィックスパワー要求増大により、CPUにボトルネックが移ってきており、これがVDI集約率向上を阻む大きな要素になっています。以下の図のように、仮想GPUソリューションを活用することで、サーバーあたりの仮想マシン集約率は向上し、OSやアプリケーションのパフォーマンスまでもが向上します。

最後に、もうひとつ、NVIDIA GPUの利用が、VMware Horizon環境のCPU負荷の低減に効く仕組みを紹介したいと思います。その名も【NVENC】（えぬぶいえんくと呼ばれてます）。VDI環境のWindowsやアプリケーションが、GPUパワーにより、快適に動作するようになっても、それだけでは、実は片手落ちです。当たり前のお話ですが、VDI上で快適に動作した結果の画面が、絶え間なく、遅延が無く、リモートのユーザーに転送されて始めて、ユーザーは、快適に動作していると感じます。VMware Horizon 7では、従来からの画面転送プロトコル PCoIPの他に、H.264の映像圧縮方式に準拠したBlast Extremeという新たに開発された画面転送プロトコルが使うことができるようになりましたが、このBlast Extremeを利用する際に嬉しい機能がNVIDIAのGPUには搭載されており、それがNVENCというわけです。どう嬉しいのかを説明します。NVENCは、NVIDIAのGPU製品に内蔵された専用ハードウェアによるエンコード機能で、H.264のエンコード処理を得意としてます。つまり、CPUに負荷をかけずに、GPU（正確にはGPU製品内のNVENC）が、VMware Blast Extremeの画面転送ができるのです。NVENCがあると、画面転送を行う際の処理の少ないことも下の図でイメージできると思います。

Windows10時代は、CPUボトルネック時代でもあります。CPUに、やって欲しいことはたくさんあるので、グラフィックス処理や画面転送処理は、それを得意とするGPUに任せるのが一番。今、使っているVDI環境をWindows10に移行しようとお考えの方、あるいは、そういったご相談を受けているSI関係の方、Windows10 VDIにはGPUは必要ですので、もっと詳細な情報に触れて頂き、活用を真剣にお考えいただきたいと思います。

最後まで、お読み頂き、ありがとうございました！　今までGPUとは縁が無かった（少なかった）方に興味を持って頂けるよう、意識して書いたつもりですが、如何でしたでしょうか。NVIDIA仮想GPUソリューションの詳しい情報は、NVIDIA社員はもちろん、VDIの経験も豊富なNVIDIA認定パートナーもおられますので、ぜひ、ご相談してみてください！

　◆NVIDIA GRID認定パートナー：仮想化パートナー - NVIDIA GRID - NVIDIA | NVIDIA

vExperts Advent Calendar 2018 13日目は 、yueisu913さんの予定です。よろしくお願いしまーす！

（vExperts Advent Calendar 2018 https://adventar.org/calendars/3101）

Kzma Ymbe（vEXPERT 山辺）

（免責）

本ブログは私が個人的に行っているブログであり、所属する会社とは関係ありません。本ブログ内の情報は、個人の見解、個人で調査した情報を記載していますので、間違っていることもあります。正確性を保証するものではありませんので、ご了承ください。

今月は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 の説明は、下記のあたりが参考になると思います。

• 監視トラフィック用のネットワーク インターフェイスの構成（vSAN 6.7 ドキュメント）
• Understanding the vSAN Witness Host - Traffic Tagging - Virtual Blocks（英語ブログ）

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

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

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

vSAN ノード #1

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

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

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

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

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

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

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

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

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

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

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

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

vSAN ノード #2

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

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

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

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

vSAN 監視ホスト

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

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

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

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

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

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

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

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 を切断状態にしています。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

つづく。

今月は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 にします。

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

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

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

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

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

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

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

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

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

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

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

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

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

vSAN ノードの追加。

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

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

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

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

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

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

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

手動で作成します。

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

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

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

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

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

削除してしまいます。

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

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 Witness Appliance による監視ホストは、停止しておきます。

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

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

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

拡張後の vSAN の様子。

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

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

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

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

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

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

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

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

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

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

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

ちなみに、ノード #3 追加前にすべての ESXi VM で 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 クラスタで、

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

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

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

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

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 側にもテスト結果が反映されていることがわかります。

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

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

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

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

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

つづく。

今月は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 ネットワーク

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

拠点間接続ルータ役の 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 と監視ホストとの間でネットワーク遅延が特にない状態です。

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 を実行しておくと、

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

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

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

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

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

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

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

今回のように物理マシン内にルータ役の 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 クラスタでは、DRS を有効にしています。

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

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

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

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

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

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

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

サーバ ラック A のホスト（192.168.1.31、192.168.1.32）で

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

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

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

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

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

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

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

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

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

ラック障害時のイメージ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

つづく。

今月は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か所になります。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

つづく。

今月は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」で起動しています。

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

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

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

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

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

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

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

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

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

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

しかし、ストレージ性能が不均等になりやすかったり、

障害時の挙動が予測しにくくなったりします。

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

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

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

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

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

つづく。

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

昨日はこちら。

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

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

vSAN-Cluster-20181219 クラスタ

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

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

重複排除・圧縮の要件により、このクラスタの ESXi は

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

クラスタ容量では、デデュープおよび重複排除の容量も

確認できるようになっています。

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

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

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

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

今回は、PowerCLI で「vm-template」を30台クローンしています。

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

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

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

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

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

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

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

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

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

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

今回のように大量 VM クローンなどでする場合は、ネストの外側の物理マシンで

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

この環境はまだ大丈夫ですが、

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

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

vCenter の VM など、重要な VM が停止してしまうと致命的なので、

このような検証をするときは、

データストア容量に注意を払う、

重要な VM をシック プロビジョニングで容量確保するか、

あらかじめ重要な VM を別の NFS データストアなどに配置しておく

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

つづく。

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

昨日はこちら。

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

20日目は、vSAN の iSCSI ターゲット サービスを有効にして、

Linux サーバから接続してみます。

vSAN-Cluster-20181220 クラスタ

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

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

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

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

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

iSCSI ターゲットによる LUN は、vSAN データストアの外部で稼働する

物理マシンからの利用も想定されます。

今回のネスト環境であれば、LUN を利用する サーバを

ネストの外側の物理 ESXi で VM として稼働させると、ネットワーク経路的に

物理マシンからの iSCSI 接続に近い構成を作りやすくなります。

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

「192.168.1.151」にしました。

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

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

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

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

そしてコンポーネントも、仮想マシン ストレージポリシーにしたがって

VM の仮想ディスクと同様に分散されます。

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）などを

利用することになるはずです。

つづく。