hidemium's blog

日々学んだことをアウトプットする。

Nested ESXiをvMotionした場合の動作について

前回の記事で、vDSを利用したMACラーニングについて書いてみましたが、今回はNested ESXiのvMotionを行った際の挙動について書いてみようと思います。

構成

  • vCenter 7.0 U2
  • ESXi 7.0 Update 2
  • ESXi 7.0 Update 3 Virtual Appliance
  • MACラーニング有効なvDSを用意

vMotion時の動作について

vMotionが行われると、別のホストへVMが移動しますが、その際に通信が切断されないように、vMotion後に移動先ホストがRARPプロトコルを利用し、接続している物理スイッチに対して、vNICのアドレスに関するMACアドレステーブルの更新を行います。

Nested ESXiをvMotionした場合の動作について

Nested ESXiのVMをvMotionした場合、Nested ESXi自身はVMと同様となりますが、Nested ESXi上に稼働しているVMがどのように扱われるかあまり情報がないため、パケットキャプチャを行い確認してみました。

vMotion後の移動先ホストにログインし、pktcap-uwを使い、パケットキャプチャを行います。pktcap-uwのオプションで、--ethtype 0xEthertype のようにEthertypeを指定できるため、RARPのEthertypeの8035を指定します。

pktcap-uw --uplink vmnic0 --ethtype 0x8035 -o /vmfs/volumes/datastore1/test.pcap

EtherType一覧

パケット フィルタ用 pktcap-uw オプション

vMotionを実行し、パケットキャプチャを取得し、pcapファイルをデータストアのファイルブラウザからダウンロードします。 Wiresharkを起動し、pcapファイルを開きます。

Nested ESXiのMACアドレスのみを抽出すると以下のようになります。vMotionのタスクが14:45:31に開始し、14:46:14に終了していました。vMotion処理中にRARPのパケットが送出され、最初は2秒後、次は4秒後、次は6秒後、次は10秒後、次は16秒後といった具合に間隔を長くし、RARPを送出していることが分かります。間隔はフィボナッチ数列になってそうです。

No.  Time    Source  Destination Protocol    Length  Info
14  2022-XX-XX 14:46:08.519875  VMware_60:e5:ed Broadcast   RARP    60  Who is 00:50:56:60:e5:ed? Tell 00:50:56:60:e5:ed
17  2022-XX-XX 14:46:10.520016  VMware_60:e5:ed Broadcast   RARP    60  Who is 00:50:56:60:e5:ed? Tell 00:50:56:60:e5:ed
18  2022-XX-XX 14:46:10.520016  VMware_60:e5:ed Broadcast   RARP    60  Who is 00:50:56:60:e5:ed? Tell 00:50:56:60:e5:ed
21  2022-XX-XX 14:46:14.520214  VMware_60:e5:ed Broadcast   RARP    60  Who is 00:50:56:60:e5:ed? Tell 00:50:56:60:e5:ed
22  2022-XX-XX 14:46:14.520215  VMware_60:e5:ed Broadcast   RARP    60  Who is 00:50:56:60:e5:ed? Tell 00:50:56:60:e5:ed
25  2022-XX-XX 14:46:20.520509  VMware_60:e5:ed Broadcast   RARP    60  Who is 00:50:56:60:e5:ed? Tell 00:50:56:60:e5:ed
26  2022-XX-XX 14:46:20.520509  VMware_60:e5:ed Broadcast   RARP    60  Who is 00:50:56:60:e5:ed? Tell 00:50:56:60:e5:ed
29  2022-XX-XX 14:46:30.521139  VMware_60:e5:ed Broadcast   RARP    60  Who is 00:50:56:60:e5:ed? Tell 00:50:56:60:e5:ed
30  2022-XX-XX 14:46:30.521139  VMware_60:e5:ed Broadcast   RARP    60  Who is 00:50:56:60:e5:ed? Tell 00:50:56:60:e5:ed
34  2022-XX-XX 14:46:46.522160  VMware_60:e5:ed Broadcast   RARP    60  Who is 00:50:56:60:e5:ed? Tell 00:50:56:60:e5:ed
35  2022-XX-XX 14:46:46.522161  VMware_60:e5:ed Broadcast   RARP    60  Who is 00:50:56:60:e5:ed? Tell 00:50:56:60:e5:ed

Nested ESXi上に稼働しているVMについては、vMotionのタスク後に1度だけRARPが送出されていることが分かります。

No.  Time    Source  Destination Protocol    Length  Info
33  2022-XX-XX 14:46:46.522159  VMware_c6:07:20 Broadcast   RARP    60  Who is 00:0c:29:c6:07:20? Tell 00:0c:29:c6:07:20

MACラーニングが無効なvDSにて、Nested ESXiのVMのvMotionを行った場合も確認しましたが、Nested ESXiのRARPは送出されていましたが、Nested ESXi上に稼働しているVMについては、RARPが送出は確認できませんでした。

物理スイッチ側の動作について確認

vMotion後に物理スイッチ側でNested ESXiのVMとNested ESXi内部にゲストOSのMACアドレスについて、MACアドレステーブルの確認します。
フレームがNested ESXiと同じポートから送出されていることが分かります。

#show mac address-table
  50    0050.5660.e5ed    DYNAMIC     Gi0/6  #Eested ESXiのvmk0
  50    000c.29c6.0720    DYNAMIC     Gi0/6     #ゲストOSのeth0

参考

仮想スイッチ”スイッチへの通知”について(1) | Lab8010

vDSのMACラーニングを利用してNested ESXiの検証環境を構築する

前回の記事で、Nested ESXiを使った検証環境の構築方法についてを書いてみましたが、今回はvDSを利用したMACラーニングについて書いてみようと思います。

構成

  • vCenter 7.0 U2
  • ESXi 7.0 Update 2
  • ESXi 7.0 Update 3 Virtual Appliance

vDSのMACラーニング機能について

vSphere 6.7から、vDS 6.6にMAC ラーニングが実装され、分散スイッチが仮想マシンMAC アドレスを学習できるようもになりました。 これにより、無差別モードが無効な場合でも、分散スイッチがMACアドレスを学習しているため、vNICのMACアドレスと異なる宛先MACアドレスのフレームを受診しても、正しいvNICにフォワーディングすることができるようになります。ただし、vNICと異なる送信元MACアドレスのフレームが送信を許可する必要があるため、偽装転送については承諾は必要となります。

Native MAC Learning in vSphere 6.7 removes the need for Promiscuous mode for Nested ESXi

事前準備

トランクポートのポートグループの作成

Nested ESXi上の仮想マシンとネットワーク疎通を取るために、トランクポートのポートグループを作成します。

  • vSphere Clientにログインします。
  • vDSを右クリックし、新規ポートグループをクリックします。
  • 新規分散ポート グループにて、VLAN タイプにVLANトランクを選択します。
  • デフォルト ポリシー設定をカスタマイズしますを選択し、次へをクリックします。
  • セキュリティにて、偽装転送を承諾に選択します。
  • 他の設定はすべてデフォルトのままとし、完了をクリックします。

vDSのMACラーニング機能の有効化について

vDSのMACラーニング機能の有効化について、上記の記事にあるPowerCLIスクリプトを利用することで実現できます。

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

> Install-Module VMware.PowerCLI

信頼されていないリポジトリ
信頼されていないリポジトリからモジュールをインストールしようとしています。このリポジトリを信頼する場合は、Set-PSReposit
ory コマンドレットを実行して、リポジトリの InstallationPolicy の値を変更してください。'PSGallery'
からモジュールをインストールしますか?
[Y] はい(Y)  [A] すべて続行(A)  [N] いいえ(N)  [L] すべて無視(L)  [S] 中断(S)  [?] ヘルプ (既定値は "N"): A

モジュールがインストールされているか確認します。

> Get-Module VMware* -ListAvailable

PowerShellの実行ポリシーを確認します。

> Get-ExecutionPolicy
Unrestricted 

vCenterに接続します。

Connect-VIServer -Server 'vcsa-1.home.lab' -User 'Administrator@vsphere.local' -Password 'password' -force

以下のスクリプトをダウンロードします。

vmware-scripts/MacLearn.ps1 at master · lamw/vmware-scripts · GitHub

PowerShellモジュールをインポートします。

> Import-Module .\MacLearn.ps1

現在のvDSのMACラーニングの設定を確認します。

Get-MacLearn -DVPortgroupName @("trunk-maclaearn")


DVPortgroup            : trunk-maclaearn
MacLearning            : False
NewAllowPromiscuous    : False
NewForgedTransmits     : False
NewMacChanges          : False
Limit                  :
LimitPolicy            :
LegacyAllowPromiscuous : False
LegacyForgedTransmits  : False
LegacyMacChanges       : False

vDSのMACラーニングを有効にします。

Set-MacLearn -DVPortgroupName @("trunk-maclaearn") -EnableMacLearn $true -EnablePromiscuous $false -EnableForgedTransmit $true -EnableMacChange $false

変更後のvDSのMACラーニングの設定を確認します。

Get-MacLearn -DVPortgroupName @("trunk-maclaearn")


DVPortgroup            : trunk-maclaearn
MacLearning            : True
NewAllowPromiscuous    : False
NewForgedTransmits     : True
NewMacChanges          : False
Limit                  : 4096
LimitPolicy            : DROP
LegacyAllowPromiscuous : False
LegacyForgedTransmits  : True
LegacyMacChanges       : False

MacLearningがTrueとなり、MACラーニングが有効になったことが分かります。またLimitが4096となり、MACラーニングの上限が4096に設定されたことが分かります。

Nested ESXi内部にゲストOSを作成

Nested ESXi内部にゲストOSを作成し、pingを実行します。

  • Nested ESXiのHost Clientにログインします。
  • ゲストOSが接続するポートグループのVLANIDを検証環境のVLANIDと合わせておきます。
  • ゲストOSは軽量のほうがテストしやすいので、Photon OSのovaイメージを利用しデプロイします。
  • Photon OSの初期パスワードはchangemeなので、パスワードを新しく設定します。
  • ゲストOSが起動後、ゲストOS内でpingの応答ができるように、FWの設定を変更します。
  • ゲストOSに対してpingを実行し、応答があるか確認します。

偽装転送を承諾にするだけで、Nested ESXi内部にゲストOSへ疎通が取れることが確認できました。

ポートグループの動作について確認

セキュリティにて、偽装転送を承諾に選択しましたが、すべて拒否にするとどうなるか確認してみます。 すべて拒否しても、pingの応答が返ってきました。偽装転送を行っても疎通が取れるのは、想定外のため詳細については別途確認してみようと思います。

ESXi上でのコマンド確認

ESXiシェルで現在学習中のMACアドレスについて詳細情報を取得することも可能です。netdebgコマンドを利用します。

[root@esxi-2:~] netdbg vswitch instance list
vSwitch0 ()                                                                     
Total Ports:2560 Available:2548
  Client                         PortID          DVPortID                             MAC                  Uplink         
  Management                     67108868                                             00:00:00:00:00:00    n/a            
  vmnic0                         2214592517                                           00:00:00:00:00:00                   
  Shadow of vmnic0               67108870                                             00:50:56:5d:b8:0f    n/a            
  vmk0                           67108871                                             94:c6:91:1d:a5:8d    vmnic0         
  vmk1                           67108873                                             00:50:56:68:a2:65    vmnic0         
  vmk2                           67108876                                             00:50:56:67:eb:63    vmnic0         

DvsPortset-0 (DSwitch)           50 38 56 06 e8 10 60 77-f9 5e 1b 6b 90 0c 9c e2
Total Ports:2560 Available:2548
  Client                         PortID          DVPortID                             MAC                  Uplink         
  Management                     100663304                                            00:00:00:00:00:00    n/a            
  vusb0                          2248146954      166                                  00:00:00:00:00:00                   
  Shadow of vusb0                100663307                                            00:50:56:54:e2:b6    n/a            
  esxi70u3a-2.eth0               100663311       167                                  00:50:56:b8:b0:ea    vusb0          
  esxi70u3a-2.eth1               100663312       168                                  00:50:56:b8:77:de    vusb0

Nested ESXiのDVPortIDを指定し、以下のコマンドを実行します。

[root@esxi-2:~] netdbg vswitch mac-learning port get -p 167 --dvs-alias DSwitch
MAC Learning:                   True
Unknown Unicast Flooding:       True
MAC Limit:                      4096
MAC Limit Policy:               DROP
[root@esxi-2:~] netdbg vswitch mac-learning port get -p 168 --dvs-alias DSwitch
MAC Learning:                   True
Unknown Unicast Flooding:       True
MAC Limit:                      4096
MAC Limit Policy:               DROP

DVポートで学習したすべてのMACアドレスを取得するには以下のように実行します。

[root@esxi-2:~] netdbg vswitch mac-table port get -p 167 --dvs-alias DSwitch
MAC: 00:0c:29:c6:07:20 vid: 0      vni: 0        type: learned   aging: yes    elapsed: 876   
MAC: 00:50:56:60:e5:ed vid: 0      vni: 0        type: learned   aging: yes    elapsed: 876   
MAC: 00:50:56:60:e5:ed vid: 50     vni: 0        type: learned   aging: yes    elapsed: 1     
MAC: 00:0c:29:c6:07:20 vid: 50     vni: 0        type: learned   aging: yes    elapsed: 118   
MAC: 00:50:56:b8:b0:ea vid: 0      vni: 0        type: static    aging: no     elapsed: 0 

物理スイッチ側の動作について確認

物理スイッチ側でNested ESXiのVMとNested ESXi内部にゲストOSのMACアドレスについて、MACアドレステーブルの確認します。
フレームがNested ESXiと同じポートから送出されていることが分かります。

#show mac address-table
  50    0050.5660.e5ed    DYNAMIC     Gi0/4  #Eested ESXiのvmk0
  50    000c.29c6.0720    DYNAMIC     Gi0/4     #ゲストOSのeth0

vMotionによる動作

vMotionを行った場合に、学習したMACは新しいポートに移動されるかという疑問が生じますが、上記の記事には同一ホスト上にNested ESXiが2台あり、そのNested ESXi上でvMotionを行っても新しいvNICポートに移動するようです。また、別のホスト上にNested ESXiが2台存在し、そのNested ESXi上でvMotionを行っても新しいvNICポートに移動するようです。

また、Nested ESXiのVM自体を別のホストにvMotionを行った場合について、動作確認を行ってみました。 vMotion後に、物理スイッチのMACアドレステーブルを確認したところ、Nested ESXi内のゲストOSについても、フレームがNested ESXiと同じポートから送出されていることが分かります。(Nested ESXiをvCenterに接続していないため、vCenterに接続されていないESXiにより自動割当てされるMACアドレスのベンダーコードは00:0C:29になります。)

#show mac address-table
  50    0050.5660.e5ed    DYNAMIC     Gi0/6  #Eested ESXiのvmk0
  50    000c.29c6.0720    DYNAMIC     Gi0/6     #ゲストOSのeth0

参考情報

Nested ESXi のテンプレート作りに必要な設定と解説 | vSoliloquy

Nested ESXiでvSphere 7.0の検証環境を構築する

vSphere環境で動作検証を行いたい場合、物理で行う場合サーバーやストレージなどHWが環境分必要となってきますが、Nested ESXiを利用するとすでにあるHWを利用し仮想的にvSphereの検証環境を用意することができます。Nested ESXiを利用した検証環境の構築は、様々なvSphereのテクニックを利用しているため、構築方法についてまとめてみたいと思います。

構成

  • vCenter 7.0 U2
  • ESXi 7.0 Update 3 Virtual Appliance

事前準備

トランクポートのポートグループの作成

Nested ESXi上の仮想マシンとネットワーク疎通を取るために、トランクポートのポートグループを作成します。

  • vSphere Clientにログインします。
  • vDSを右クリックし、新規ポートグループをクリックします。
  • 新規分散ポート グループにて、VLAN タイプにVLANトランクを選択します。
  • デフォルト ポリシー設定をカスタマイズしますを選択し、次へをクリックします。
  • セキュリティにて、無差別モードと偽装転送を承諾に選択します。
  • 他の設定はすべてデフォルトのままとし、完了をクリックします。

DHCPサーバーの用意

Nested ESXiのIPアドレスの設定を楽にするために、DHCPサーバーを用意しておきます。
自宅ではEdgeRouterのDHCPを利用していますが、VyOSなどでDHCPサーバーを利用するのも良いかと思います。

Nested ESXi Virtual Applianceのダウンロード

まずは、以下のサイトからNested ESXi Virtual Applianceをダウンロードします。
VMwareの中の人が、Nested ESXiに必要な設定入れビルドしたovaイメージを公開してくれています。
コンテンツライブラリの公開ライブラリも公開されています。

Nested ESXi Virtual Applianceのデプロイ

Nested ESXi Virtual ApplianceをvCenterにデプロイしていきます。

  • vSphere Clientにログインします。
  • デプロイ先のオブジェクトを選択し、右クリックし、OVF テンプレートのデプロイをクリックします。
  • ローカル ファイルでダウンロードしたovaイメージを選択します。
  • コンピューティングリソースやストレージを選択します。
  • ネットワークの選択で先ほど作成したトランクポートのポートグループを選択します。
  • テンプレートのカスタマイズでNetworkingはDHCPを有効にしているため、空白にしておきます。
  • テンプレートのカスタマイズでFollow Hardware MAC Addressを有効にしておきます。
  • 設定の確認にて、完了をクリックします。

Nested ESXi内部にゲストOSを作成

Nested ESXi内部にゲストOSを作成し、pingを実行します。

  • Nested ESXiのHost Clientにログインします。
  • ゲストOSが接続するポートグループのVLANIDを検証環境のVLANIDと合わせておきます。
  • ゲストOSは軽量のほうがテストしやすいので、Photon OSのovaイメージを利用しデプロイします。
  • ゲストOSが起動後、ゲストOS内でpingの応答ができるように、FWの設定を変更します。
  • ゲストOSに対してpingを実行し、応答があるか確認します。

ポートグループの動作について確認

セキュリティにて、無差別モードと偽装転送を承諾に選択しましたが、すべて拒否にするとどうなるか確認してみます。 すべて拒否すると、pingの応答が返ってこないことがわかります。

標準スイッチのトラフィックは、仮想マシンネットワークアダプタMACアドレスモードの一部を制限することで、レイヤー2攻撃から保護することができます。 vSwitchの各ポート配下ではNested ESXiと、Nested ESXi内部のゲストOSのMACアドレスが使用されるため、Nested ESXiのVMのvNICのMACアドレスとは異なるMACアドレスが送信的や宛先に設定されたEthernetフレームがvNICで送受信されることになります。そのため、標準スイッチのセキュリティオプションにより、フレームが破棄されますが、偽装転送を承諾することでvNICと異なる送信元MACアドレスのフレームが送信を許可し、無差別モードを承諾することで、vNICのMACアドレスと異なる宛先MACアドレスのフレームを受診することができるようになります。

vSphere 標準スイッチのセキュリティ強化

物理スイッチ側の動作について確認

物理スイッチ側でNested ESXiのVMとNested ESXi内部にゲストOSのMACアドレスについて、MACアドレステーブルの確認します。
フレームがNested ESXiと同じポートから送出されていることが分かります。

#show mac address-table
  50    0050.5664.ec6e    DYNAMIC     Gi0/6  #Eested ESXiのvmk0
  50    000c.296c.6351    DYNAMIC     Gi0/6     #ゲストOSのeth0

Nested ESXiの展開方法について

以前は、Nested ESXiのVMに設定を入れ、テンプレート化しクローンによる展開が可能でしたが、ESXi7.0 Update2以降はクローンの作成が安全ではなくなりました。ESXiのUUIDが重複することで、ESXiからVMFSを共有するとVMFSが破損する可能性があるようです。

利用する検証環境の構成次第では影響が出ないようにできるかもしれないですが、シンプルに対応しようとすると、Nested ESXi Virtual Applianceを電源を一度も上げずにVMのテンプレート化し、構築するたびに設定を入れるのがよさそうに見えています。

How to properly clone a Nested ESXi VM?

また、/Net/FollowHardwareMac の設定ではvmk0しかMACアドレスをvNICに追従できないため、追加のVMkernelを設定したい場合は、 クローン後に追加する必要があります。

参考情報

Nested ESXi のテンプレート作りに必要な設定と解説 | vSoliloquy

vCenter 7.0でActive Directory over LDAPSを構成する

久しぶりにブログを更新してみようと思います。

vCenter 7.0からWindows統合認証が非推奨となり、LDAP/LDAPSかAD FSが推奨となりました。 Windows統合認証はWindows版vCenterがあった時代は、OSがWindowsであったため構成上問題はありませんでしたが、現在はPhoton OSのアプライアンス版しか存在しないため、Linux環境でWindowsの認証を利用必要があり複雑性が増していることから廃止予定となったようです。

f:id:hidemium:20220129073200p:plain

ただし、ユーザ認証の設定について既存のADを利用する場合など考慮事項も多いため、設定変更を行う手順について確認を行ってみました。

構成

Active DirectoryのLDAPSの設定

Active Directoryがすでに設定済みの環境を用意します。 Active Directoryは初期設定ではLDAPSに利用される689ポートが開いていますが、証明書が登録されていないため、すぐに利用することはできません。

LDAPSを有効化させる方法は2つの方法があります。

今回はエンタープライズCAを利用した方法を確認してみようと思います。

エンタープライズCAのインストール

Windows Server 2019 (AD CS)でエンタープライズCAのインストールを行っていきます。

  • Windows Server 2019 (AD CS)をドメイン参加させておきます。
  • サーバーマネージャのダッシュボードから役割と機能の追加をクリックします。
  • インストールの種類で役割ベースまたは機能ベースのインストールを選択し、次へをクリックします。
  • サーバーの役割で、Active Directory証明書サービスを選択し、機能の追加を選択します。
  • Active Directory証明書サービスの役割サービスで証明機関を選択し、次へをクリックします。
  • インストールをクリックし、インストールを行います。
  • 対象のサーバーに Active Directory 証明書サービスを構成するをクリックします。
  • 資格情報にて、ドメインの管理者アカウントが入力されていることを確認し、次へをクリックします。
  • 役割サービスにて、認証機関を選択し、次へをクリックします。
  • セットアップの種類にて、エンタープライズ CAを選択し、次へをクリックします。
  • CAの種類にて、ルートCAを選択し、次へをクリックします。
  • 秘密キーにて、新しい秘密キーを作成するを選択し、次へをクリックします。
  • CAの暗号化にて、RSA#Microsoft Software Key Strong Provider、 キー長に2048、SHA256を選択し、次へをクリックします。
  • CAの名前にて、CAの名前を指定し、次へをクリックします。
  • 有効期間にて、CA証明書の有効期間の長さを入力し、次へをクリックします。
  • CAデータベースにて、証明書データベースを入力し、次へをクリックします。
  • 確認にて、設定値を確認し、構成をクリックします。
  • サーバーマネージャのダッシュボードからツール>証明機関をクリックし、グリーンのチェックマークがついていればインストールは完了です。 f:id:hidemium:20220129064828p:plain

ADサーバーの証明書の発行の確認

エンタープライズCAから自動的にサーバー証明書が発行されることを確認します。
タスクスケジューラでサーバー起動時か8時間ごとに自動的に処理が行われているため、サーバーの再起動かタスクスケジューラのWindows>CertificateServiceClient>SystemTaskを実行します。

  • ファイル名を指定して実行に mmc と入力し、コンソールを起動します。
  • ファイルからスナップインの追加と削除をクリックします。
  • スナップインの追加と削除にて、証明書を選択し、追加をクリックします。
  • コンピューターアカウントを選択し、完了をクリックします。
  • そのままで完了をクリックします。
  • 選択されたスナップインに証明書が追加されたことを確認し、OKをクリックします。
  • 個人>証明書をクリックし、サーバー証明書の発行を確認します。 f:id:hidemium:20220129065539p:plain

ルート証明書のダウンロード

ルート証明書の取得方法はいくつかあります。

  • エンタープライズCAの証明機関から取得
  • ADサーバーのコンソールから取得
  • openssl s_clientコマンドによる取得

openssl s_clientコマンドによる取得した際に、サーバー証明書は取得できますが、 ルート証明書が自己署名されているため、ルート証明書の取得ができません。
そのため、エンタープライズCAからの証明機関から取得してみます。

  • サーバーマネージャのダッシュボードからツール>証明機関をクリックします。
  • グリーンのチェックマークがついているアイコンを右クリックし、プロパティをクリックします。
  • 証明書の表示をクリックします。
  • 証明書にて、詳細タブをクリックし、ファイルにコピーをクリックします。
  • 証明書のエクスポートウィザードにて、次へをクリックします。
  • Base-64 encoded X.509 (.CER)を選択します。
  • エクスポートするファイルにて、ファイル名に ca.cer などを入力し、次へをクリックします。
  • 完了をクリックします。
  • エクスポートした証明書を手元の環境にダウンロードします。 f:id:hidemium:20220129072405p:plain

vCenterのIDソースの設定

最後にvCenterへLDAPSのユーザ認証の設定を追加します。

  • vSphere Clientにadministrator@vsphere.localユーザでログインします。
  • 管理>Single Sign-On>設定をクリックし、IDプロバイダ>IDソースで追加をクリックします。
  • IDソースの追加にて、IDソースタイプにLDAPを介したActive Directoryを選択し、以下のような値を入力します。
    • IDソース名: Active Directory over LDAPS
    • ユーザーのベース識別名: cn=Users,dc=home,dc=lab
    • グループのベース識別名: cn=Users,dc=home,dc=lab
    • ドメイン名: home.lab
    • ユーザー名: administrator@home.lab
    • プライマリ サーバ URL: ldaps://windows2019-1.home.lab:636
  • 証明書(LDAPSの場合)の参照をクリックし、先の手順でダウンロードしたルート証明書を登録します。 f:id:hidemium:20220129073501p:plain
  • 保存をクリックします。
  • 以下のように設定が保存されれば、LDAPSのIDソースの追加が完了です。 f:id:hidemium:20220129074636p:plain
  • 一度vSphere Clientからログアウトし、ADユーザでログインできることを確認します。

エラーが発生するケースについて

保存をクリックした際に、設定に問題がある場合はエラーが発生することがあります。

  • プライマリ サーバ URLにIPアドレスを設定
    • FQDNでの登録が必要です
    • vCenterで名前解決ができる必要があります
  • 証明書が誤ったものを登録

LDAPを介したActive Directoryの課題について

LDAPを介したActive Directoryに設定を移行した場合、以下の課題があるように見えます。

  • LDAPで登録し、LDAPSに切り替えたい場合、一度IDソースとして削除し再登録する必要がある
  • LDAPSで登録し、証明書の有効期限が切れた場合、一度IDソースを削除し再登録する必要がある
  • サーバー証明書を証明書と登録した場合、エンタープライズCAのデフォルト設定で1年間に1回サーバー証明書が更新されるめ、再登録が必要

LDAPSの証明書の有効期限が切れた場合に、新しい証明書を追加で登録できないため、 IDソースを切り替える際にユーザ認証ができないという課題があり、この辺りの考慮が必要になってきそうです。 vCenterのCLIツールでIDソースの再登録を自動化するという手もあるかもしれません。

参考情報

育児を効率化するために自宅をスマートホーム化してみた

この記事はFJCTアドベントカレンダー2018 5日目の記事です。FJCTでエンジニアをしている id:hidemium です。

本記事は、普段の仕事ではなく、育児についての話をしてみようと思います。

前の記事で、育休を1ヶ月取得した時の内容を書きましたが、3か月近くが経過したので変化してきたことや、育児を効率化するために行った自宅のスマートホーム化についてより詳細に書いてみようと思います。

概要

利用しているアプリ

まずは、育児で利用しているアプリをいくつか紹介します。

Trello

  • かんばんベースのタスク管理ツール
  • 予防接種など育児に関するタスクを夫婦間で共有するために利用
  • 非エンジニアの妻でも問題なく使用ができています。
  • こちらは引き続き利用しています。

みてね

  • 家族で写真を共有するためのアプリ
  • 生後何か月の写真か自動的に分類できるため、日々の変化を振り返ることができます。
  • アプリを使い慣れていない親世代にも、アプリ導入やコメント追加がシンプルで好評でした。
  • こちらは引き続き利用しています。

ぴよログ

  • ミルクや排泄の時間などを記録するためのアプリ
  • 粉ミルクから母乳にシフトしてきたため、利用頻度は低下しました。

Amazon

  • AmazonプライムAmazonファミリー会員に登録すればおむつが15%オフで買えるため便利です。

買ってよかったもの

次に、買ってよかったものを紹介します。こちらも少し変化してきました。

メイプルウェア ホットウォッシュ

  • 40度前後の温水をキープして、温水でおしりふきができるもの。
  • アルコールのおしりふきと比べて、肌荒れがなく硬くなった排泄物も取れやすいのが良かったです。
  • 引き続き便利に使っています。

チェンジングテーブル

ベビーバス

  • キッチンでの沐浴からお風呂場になったため、利用しなくなりました。

Google Home

  • 子供を抱っこする回数が増え、家電の操作がしづらくなっため利用しています。
  • こちらについて、以下で詳しく書いています。

食洗器

  • 育児する側も食事をとる必要があるので、負荷軽減のため必須

乾燥機付き洗濯機

  • 育児する側と合わせて子供の洗濯物が増えるため、負荷軽減のため必須

スマートホーム化について

最近ではスマートホームの機器や実例はたくさん出てきていますが、Goolge HomeとNature Remo、SwtichBotを取り入れてみました。

自宅のネットワーク構成は以下にようになっており、Edgerouteを使ってリビング用とHome Lab用にVLANを分けています。 リビング用のネットワークには無線LANのアクセスポイントがあり、こちらにGoolge Homeなどの機器が接続されています。

Google Homeの音声入力を使って家電を連携するためにはNature Remo、SwtichBotが必要となります。

Nature RemoはWifi機能のついた赤外線通信機能を持ったデバイスで、Wifiを通じて赤外線で操作できる家電のコントロールをすることができます。

また、SwtichBotは物理スイッチを押すための小型ロボットになり、こちらもWifiを通じて物理スイッチのオンオフができます。物理スイッチのオンができるものはいくつかありますが、オフができるものは現在のところ、これしかないかもしれません。SwtichBot Hubを使うとWifi機能が利用できます。SwtichBot Hub Plusは赤外線通信機能が搭載されましたが、一部の家電で操作ができなかったため、今回は物理スイッチの利用のみとなります。

Google Homeにはスマート家電と連携できる機能が増えて来ていますが、よりカスタマイズをするためにIFTTTを利用しています。 IFTTTはWebサービス同士を連携できるサービスになり、Google Homeの音声入力をしたいフレーズをトリガーに対象の家電の操作を実行できるように連携することができます。

全体として、以下のような流れとなります。

例えば、照明をつける場合、IFTTTに以下のような設定を行います。

trigger service simple phrase action service action
Google Assistant おはよう Nature Remo 照明 - オン

エアコン、TV、シーリングライトなどの各家電の操作ごとにこのような設定を追加していきます。

また、以下のようにワンフレーズだけで複数の家電を操作するように設定することもでき、同時操作できるようになるとさらに威力を発揮します。

trigger service simple phrase action service action
Google Assistant おはよう Nature Remo 照明 - オン
Google Assistant おはよう Nature Remo エアコン - オン

このような設定をすることで、子供を抱っこして手がふさがった状態でも家電の簡単な操作を行うことができるようになりました。

家電の操作以外でも、Spotifyと連携して音楽を聞いたり、料理中のタイマーとしても利用しています。

照明関連で困ったこと

ただし、すべて快適になったわけではなく、いくつか課題はありました。

まず夜間にGoogle Homeに音声入力するのが難しいという問題があります。はっきりしたフレーズではないと、Google Homeに聞き取ってもらえないため、何度か言い直さないといけないという問題がありました。 また、Google Homeの操作対象にしているリビングの電気自体が明るいため、睡眠を妨害してしまうということがあります。

そこで、Google Homeによる操作ではなく、センサーが付いたライトをいくつか利用しています。

人感センサーライト

明暗センサーライト

ベッドサイドランプ

  • 夜中に子供の確認を利用するために利用しています。
  • ほのかな明かりであり、オンオフがタッチセンサーのため音がしないため、睡眠を妨害しないので便利です。 [asin:B0785DQRX6:detail]

最後に

スマートホーム化や買ってよかったものについて紹介しました。

育児は、お風呂に入れたり、泣いたときに抱っこをするなど大部分の作業は効率化が難しいところもあり、スマートホーム化を行ったかといって劇的に楽になるわけではありませんが、ちょっとして作業を楽にはできると思っています。このような取り組みをすこしずつ取り入れ、育児を少し楽にしつつ、子供と触れ合える時間をより多くできるようにしたいと思っています。

明日は @SugiC さんの Alexa でおうちはっくの話です。

男性エンジニアが育休を取得してみた所感と育児グッズ紹介

育休を1ヶ月取得しており、ちょうど1か月が経過したので、エンジニアの視点で感じたことを記録しておこうと思います。毎年便利になってくると思うので、2018年はこのような感じだったなと振り返れば面白いかもしれないです。

概要

  • 利用しているサービス
  • 買ってよかったもの
  • 1日の流れと運用ナレッジ
  • 書籍
  • 育休のメリット
  • 育児をして気が付いたこと

利用しているサービス

Trello

  • かんばんベースのタスク管理ツール
  • 1か月検診やベビー用品の購入リストなど育児に関するタスクを夫婦間で共有するために利用
  • 非エンジニアの妻でも問題なく使用ができている。
  • かんばんやアジャイル開発に詳しいほうが主導して利用すると運用しやすいと思う。
  • 育児以外にもTrelloを利用しており、このツールがなかったら、効率的に家族内のタスク管理はできなかったと思う。

みてね

  • 家族で写真を共有するためのアプリ
  • Google フォトと悩みましたが、幼児期や家族内のでの共有に特化しており、生後何か月か自動的に分類できるので気軽に使えるために採用
  • アプリを使い慣れていない親世代にも、アプリ導入やコメント追加がシンプルで好評でした。

ぴよログ

  • ミルクや排泄の時間などを記録するためのアプリ
  • 育休中のパパとママ両方から更新が必要だったため採用
  • まとめページで記録をグラフ化してくれるため便利
  • 他のアプリは一人でしか更新ができないものも多く、育児を共同でするという考えがなさそうで残念でした。

パパっと育児

  • ミルクや排泄の時間などを記録するためのアプリ
  • 共同編集ができなさそうだったので見送りました。
  • 泣き声から赤ちゃんが欲していることを推測してれる機能は面白かったが、精度があまり高くない。
  • 赤ちゃんが欲していることを推測するというのは、子育てにおいて結構重要だが、音声から推測するというアプローチは精度が高くするのが難しいそう。
  • 推測精度が高いものがあれば今すぐにでも欲しいが、子育てしている親ですら泣き声や動きから推測が難しいので、別のアプローチ方法のほうがいいかもしれない。

コープデリ

  • 宅配サービス
  • 複数の宅配サービスと比較して、商品数の多さと子育て割引きがあることから採用
  • アプリのUIは独特すぎて慣れるまで時間がかかる。
  • 定期購入はWebからしか追加できないので、アプリで完結できるようにしてほしい。
  • カット済みの食材や調味料がセットになったミールキットは、短時間で料理が出来るので便利だった。

Amazon

メルカリ

  • ベビー用品を格安で入手するために利用
  • べビー用品は利用する期間が限られているため、直ぐに不要になるものもあるためフリマアプリと相性がいいと思う。
  • 家にある不用品を出品して、ベビー用品に変換していく。

YouTube

  • 抱っこや沐浴の方法などの動画があり、両親学級だけで不足している知識を補うために利用
  • わらべ歌も豊富なので、今後利用していこうと思う。

買ってよかったもの

メイプルウェア ホットウォッシュ

  • 40度前後の温水をキープして、温水でおしりふきができるもの。
  • アルコールのおしりふきと比べて、肌荒れがなく硬くなった排泄物も取れやすいのが良かった。
  • これがなかったら、快適なおむつ交換ができなかったと思う。
  • ミルクを一時的に保温しておくのにも便利だった。
    MAPLE WARE メイプルウェア ホットウォッシュ

    MAPLE WARE メイプルウェア ホットウォッシュ

チェンジングテーブル

  • おむつ交換台があると、腰への負担を軽減してくれるのでとても助かった。
  • 届いた木材の加工精度が低く、一部木材を削って組み立てざるを得なかったが、安いので問題はないレベルだった。
  • おむつ交換台の両サイドに収納バスケットを設置すると、おむつやベビーコットン、ごみ箱を置けるので作業効率が各段に上がった。
  • 台の下に格納スペースもあるので、ベビー用品を格納できるので便利だった。

足元灯

トッポンチーノ

ベビーバス

スリング

Google Home

  • 赤ちゃんを抱っこしていると家電の操作がしづらくなるため利用
  • 家電操作のため、NatureRemoとSwtichBotを同時に利用
  • 授乳のため夜中にGoogle Homeを使うとふらふらして音声がはっきりせず誤動作が多くなるため、CMのようにはならない。
  • 少し便利になるぐらいなのであまり期待はしないほうがいい。

食洗器

  • 育児する側も食事をとる必要があるので、負荷軽減のため必須

乾燥機付き洗濯機

  • 育児する側と合わせて赤ちゃんの洗濯物が増えるため、負荷軽減のため必須

1日の流れと運用ナレッジ

新生児の運用作業は、赤ちゃんが泣いてからその欲求を満たす作業となります。基本的には、泣き声の原因分析とおむつ交換と授乳と沐浴の4つになります。授乳はだいたい3時間毎に発生するが、おむつ交換を含めると毎時間何かしらのイベントは発生します。イベントの発生頻度を抑えることは難しいので、各作業を短縮する方向になります。

泣き声の原因分析

  • 赤ちゃんが泣いた原因を調べるフェーズ
  • おむつのおしっこお知らせサインの有無とぴよログの記録から前回の授乳時間を確認する。
  • 黄昏泣きなど泣き声の原因が不明な場合もあり、一番時間がかかる場合もある。
  • お腹が減ったか、おむつを交換したいか、抱っこしてほしいだけかの判別が難しい場合があり、赤ちゃんが欲していることを正確に推測してれるサービスがあると今直ぐにでも欲しい。

おむつ交換

  • チェンジングテーブルの周囲に収納ボックスを配置して、収納ボックスに必要なものを配置しておきおむつ交換を行う。
  • パンパースは他のメーカーに比べておしっこお知らせサインが良く見えて、少し大きいつくりなので履かせやすいので便利だった。

授乳

  • ぴよログの記録を確認しつつ、2時間30分が経過したあたりからミルクの準備を始める。
  • 哺乳瓶は最初2個からスタートしたが、哺乳瓶を洗う量が増えてもまとめ洗いを行い頻度を低くしたほうが効率がいいため、4個で運用している。
  • 粉ミルクは、キューブタイプのほほえみらくらくキューブを利用しており、40ml単位でミルクを用意できるので便利。(他のメーカーは100ml単位で粉ミルクが分けられているので調整しにくい)
  • 夜間の授乳時には、足元灯が光っており、部屋の電気をつける時と比べて光の強度が低いため、睡眠への影響を軽減できる

沐浴

  • キッチンのシンクに、ビニールタイプのベビーバスを入れ、腰の負担を軽減しつつ沐浴を行う。

書籍

育児の書籍は数多くあるが、基本的な書籍を数冊購入し、基本的な情報はその書籍で確認し、必要に応じてネットで情報収集するのがちょうど良いかと思う。(もちろん、医師や助産師からのアドバイスは真摯に聞いた上で)

最新版らくらくあんしん育児 (よくわかる)

最新版らくらくあんしん育児 (よくわかる)

育休のメリット

育休を通して以下のようなメリットがありました。

  • 新生児期は赤ちゃんが日々変化してくため、間近で成長を見ることができること
  • 夫婦間で育児について考える時間をたくさん取ることができる。
  • 育児中のトラブルを夫婦で対応することで、問題解決がスムーズにでき、夫婦間の信頼が向上する。(チーム開発と似ている)
  • 育児に関するオペレーションについて技量が向上するので、妻のサポートに入りやすくなる。

育児をして気が付いたこと

育児をしてして気が付いたこととしては以下のようなものがありました。

  • 3時間ごとに授乳が必要なため、遠出をするためには街中の授乳スペースが必要であること
  • 遠出をした場合に、ベビーカー置き場があるととてもありがたいこと
  • ベビーカーで移動する場合、街中の凹凸が走行にかなり影響すること

最後に

育休を取得したことで、育児へフルタイムで参加でき、子供と触れ合える時間をとることができ貴重な経験ができました。ベビー用品は、BabyTechという言葉が出てきたように、医学、化学、機械、情報など様々な分野の成果が反映されており、今後もどんどん便利になっていってほしいです。

VMware WorkstationにvSphere 6.5/Virtual SAN 6.5を構築する

この記事は NIFTY Advent Calendar 2016の 21 日目の記事です。

昨日は@licht110さんのserverspec+ansible+vagrant-vsphereでやるテスト駆動サーバー運用という記事でした。

ハイパーコンバージドインフラストラクチャが注目されていますが、VMwareでは、x86サーバを複数台束ねて仮想的なストレージを構築できるVirtual SANという機能を提供しています。
ただし、Virtual SANを試すためには、最低3台のホストを用意する必要があり、検証環境を用意するのも敷居が高くなっています。 今回は、自宅でもVirtual SANを試せるように、VMware Workstation上にオールフラッシュのVirtual SAN 6.5を構築する方法を紹介します。

構成

  • vCenter 6.5 (2vCPU、10GB MEM)
  • ESXi6.5 (Nested) (2vCPU、6GB MEM) x 4
  • Virtual SAN 6.5
  • VMware Workstation 11.1.4 *1
  • SSD (PC側)

インストール

仮想ネットワークの設定

Workstationの仮想ネットワーク エディタを開き、ホストオンリーのネットワーク(プライベートネットワーク)を2つ作成し、以下の用途とします。

名前 用途
VMnet1 Management Network、Virtual Machine Network、vMotion Network
VMnet2 VSAN Network

DNSサーバの構築

vCenterのデプロイで必須となるため、まずは、DNSサーバを用意します。
vSphere Web Clinentでの操作が必要となるので、今回はWindows Server 2012 R2をWorkstationにデプロイし、機能と役割からDNSサーバをインストールします。
DNSサーバの構築方法は省略しますが、vCenterのホスト名が名前解決できるように、DNSサーバに前方参照ゾーンと、Aレコードを追加しておきます。

Nested ESXiの構築

ESXi 6.5 Virtual Appliance is now availableにて、Nested_ESXi6.5のアプライアンスが提供されており、Nested_ESXi6.5_Appliance_Template_v1.ovaというファイルをダウンロードします。
アプライアンスの構成は以下のようになっています。

  • ESXi 6.5 OS
  • GuestType: ESXi 6.5
  • vHW 11
  • 2 vCPU
  • 6GB vMEM
  • 2 x VMXNET vNIC
  • 1 x 2GB HDD (ESXi Installation)
  • 1 x 4GB SSD (for use w/VSAN, empty by default)(SSDとしてラベル済み)
  • 1 x 8GB SSD (for use w/VSAN, empty by default)(SSDとしてラベル済み)

ダウンロードしたovaファイルをダブルクリックし、Workstationに追加します。
OSを起動する前に、VMの設定の変更を行います。VMの設定の変更は、VM>設定を開き、Intel VT-x/EPT または AMD-V/RVI を仮想化の有効化と、ネットワークアダプターにVMnet1、ネットワークアダプター2にVMnet2を設定します。

f:id:hidemium:20161220224503p:plain

VMの起動後に、DCUIにログインし、パスワードの追加(初期ではパスワードが空のため)と、Management NetworkのIPを追加します。
今回は、Virtual SANの検証をするため、Nested ESXiを4台用意します。

vCenter Server Appliance (VCSA)の構築

VCSAのisoファイル(VMware-VCSA-all-6.5.0-4602587.iso)をダウンロードし、isoファイルとしてマウントします。
マウントしたディスクのvcsa配下にVMware-vCenter-Server-Appliance-6.5.0.5100-4602587_OVF10.ovaというovaファイルがあるので、ovaファイルをダブルクリックし、Workstationに追加します。

OSを起動する前に、VCSAのVMのvmxファイルを開き、以下の内容を追記します。

guestinfo.cis.deployment.node.type = "embedded"
guestinfo.cis.appliance.net.addr.family = "ipv4"
guestinfo.cis.appliance.net.mode = "static"
guestinfo.cis.appliance.net.pnid = "vcenter65-1.lab.local"
guestinfo.cis.appliance.net.addr = "192.168.229.170"
guestinfo.cis.appliance.net.prefix = "24"
guestinfo.cis.appliance.net.gateway = "192.168.229.1"
guestinfo.cis.appliance.net.dns.servers = "192.168.229.10"
guestinfo.cis.appliance.root.passwd = "VMware1!"
guestinfo.cis.appliance.ssh.enabled = "True"
guestinfo.cis.deployment.autoconfig = "True"
guestinfo.cis.appliance.ntp.servers = "pool.ntp.org"
guestinfo.cis.vmdir.password = "VMware1!"
guestinfo.cis.vmdir.site-name = "default-site"
guestinfo.cis.vmdir.domain-name = "vsphere.local"
guestinfo.cis.ceip_enabled = "False"

VCSAのVMを起動すると、上記の設定が自動的に追加されます。VCSAの初回起動には時間がかかるので、しばらく待ちます。

なお、DNSサーバを用意しない場合、VCSAの初回起動時に以下のエラーが出ることがあり、はまりました。

Encountered an internal error. Traceback (most recent call last): File "/usr/lib/vmidentity/firstboot/vmidentity-firstboot.py", line 2017, in main vmidentityFB.boot() File "/usr/lib/vmidentity/firstboot/vmidentity-firstboot.py", line 349, in boot self.configureSTS(self.__stsRetryCount, self.__stsRetryInterval) File "/usr/lib/vmidentity/firstboot/vmidentity-firstboot.py", line 1478, in configureSTS self.startSTSService() File "/usr/lib/vmidentity/firstboot/vmidentity-firstboot.py", line 1140, in startSTSService returnCode = self.startService(self.__sts_service_name, self.__stsRetryCount * self.__stsRetryInterval) File "/usr/lib/vmidentity/firstboot/vmidentity-firstboot.py", line 88, in startService return service_start(svc_name, wait_time) File "/usr/lib/vmware/site-packages/cis/utils.py", line 784, in service_start raise ServiceStartException(svc_name) ServiceStartException: { "resolution": null, "detail": [ { "args": [ "vmware-stsd" ], "id": "install.ciscommon.service.failstart", "localized": "An error occurred while starting service 'vmware-stsd'", "translatable": "An error occurred while starting service '%(0)s'" } ], "componentKey": null, "problemId": null }


This is an unrecoverable error, please retry install.
If you run into this error again, please collect a support bundle and opne a support request.

起動した後で、VCSAにログインし、VCSAにNested ESXiを追加します。ホストを追加するとこのようになります。vSphere 6.5では、以前のバージョンと比べてWeb Clinetのナビゲーションの構成が変わっています。

f:id:hidemium:20161220230826p:plain

Virtual SANクラスタの構築

Virtual SANネットワークの設定

ESXiに2本NICが刺さっているので、vmnic0をvSwitch、vmnic1をVirtual SAN用のvDSとして構成します。

f:id:hidemium:20161220232442p:plain

さらに、各ESXiにVirtual SAN用のVMkernel Adapterを作成し、Virtual SAN用のvDSに所属させます。

f:id:hidemium:20161220232638p:plain

Virtual SANクラスタの有効化

Virtual SAN用クラスタのConfigure>Generalから、Configureをクリックし、Virtual SANの構成ウィザードを開きます。ストレージへのディスクの追加モードや、クラスタでデデュープおよび圧縮を有効にするオプション、クラスタのフォールトトレランスのモードがありますが、まずは初期設定のまま進みます。

f:id:hidemium:20161220233913p:plain

次に、Virtual SAN用ネットワークの検証が行われます。

f:id:hidemium:20161220234406p:plain

手動モードとしたので、クラスタごとに使用するディスクを確認します。4GB SSDはキャッシュ用、8GB SSDはキャパシティ用として利用します。

f:id:hidemium:20161220234435p:plain

構成ウィザードが終わると、Virtual SANの構成が開始されるので、タスクが完了するまで少し待ちます。

ストレージポリシーの作成

Virtual SANの設定が完了したので、次はストレージポリシーを作成していきます。Virtual SANでは、ミラー数やストレイピング数などをストレージポリシーによって定義し、VMに適用することで、VMごとのサービスレベルを設定することができます。

Policies and Profiles>VM Storage Prolicies>Virtual SAN Default Storage Policyを選択します。Manage>Rule-set1: VSANから、Editをクリックし、ストレージポリシーの設定画面を開きます。

f:id:hidemium:20161221000203p:plain

許容障害数(failures to tolerate = FTT)で、何台の物理ホスト障害に耐えらるか設定でき、今回は1としておきます。また、Add-ruleから障害の許可方法を追加し、RAID-5/6 Erasure Codingを選択します。イレージャコーディングを使用すると、ミラーリング (RAID 1) と同じレベルのデータ保護が可能であるのに加えて、使用するストレージ容量が少なくて済みます。

仮想マシンへのストレージポリシーの適用

ストレージポリシーが用意できると、仮想マシンを作成する段階で、ストレージポリシーを選択することができます。ここで先ほど作成した、ストレージポリシーを適用することで、ストレージポリシーに従ってFTTやRAIDが決定されます。

f:id:hidemium:20161221001114p:plain

Virtual SANの稼働状態の確認

最後に、Virtual SANで実際にどのように仮想マシンのデータが管理されているか確認しておきます。
Cluster>Monitor>Virtual SAN>Capacityを見ると、データの使用量を確認できます。クラスタでデデュープおよび圧縮を有効にした場合、下のようにDeduplication and Compression Overviewに圧縮しなかった場合と圧縮した場合のデータの使用量が見え、デデュープおよび圧縮により6GB->4GBとストレージの効率が良くなっていることが分かります。

f:id:hidemium:20161221001823p:plain

また、仮想マシン>Monitor>Policiesを見ると、仮想マシンのvmdkファイルがRAID-5で各ホストに分散されて管理されていることが分かります。

f:id:hidemium:20161221002624p:plain

最後に

WorkstationにvSphere 6.5 & Virtual SAN 6.5を構築してみましたが、一通りVirtual SANの設定ができ、VCSAの操作ももたつくことなく等の問題はありませんでした。Virtual SANの操作感や設定を試してみる方法として良いのではと思います。(ただ、メモリがとても必要なので潤沢にメモリを用意しましょう。)
今後は、障害時の動作など、色々試してみようと思います。

明日は@tsubasaogawaさんの記事です。お楽しみに。

参考

*1:ただし、メモリは32GB程度必要になります。