vSANデータストア上の仮想マシンディスクサイズ
今回はVMware環境でよく利用されているvSAN構成を構築したので、実際に利用される仮想マシンのディスクサイズについて調べた結果をまとめてみます。
vSANの機能面の説明は以下のVMware Japan Blogに書かれているので、知らない方はみておくと後述の理解の参考になります。
今回はvSANを有効化してvSANデータストアを構築したので、仮想マシンのディスクサイズの見え方について確認してみました。
環境構成
vCenter Server：vCenter Server 7.0 Update2
ESXi：ESXi 7.0 Update2 (3台)
仮想マシン：CentOS7
ディスクサイズとストレージポリシーの確認
今回はvSANのデフォルトとして設定される[vSAN Default Storage Policy]を設定しています。「許容される障害の数」は1件の障害としている為、RAID-1(ミラーリング)となり仮想マシンのディスクがミラー化されて作成されます。
また、仮想ディスクはシンプロビジョニングディスクとして構成されます。
仮想マシンのサマリ画面からストレージ使用量をみると、9.13GB となっていますね。
vSANデータストア上の仮想マシンのディスクサイズの確認
実際にvSANデータストア上の仮想マシンのディスクサイズを見ていきます。
vSANデータストアや健全性などの情報はクラスタを選択してGUI上から確認していく事になります。
クラスタの監視タブを選択し、vSANのカテゴリ内で[仮想オブジェクト]を選択すると、vSANデータストア上にある仮想マシンがリストされてきます。
同じvSANのカテゴリ内で[容量]を選択すると、vSANデータストアの使用済みの領域が確認できます。
画面の下へスクロールすると使用量の内訳が出力されていますが、仮想マシンのVMDKファイルは[プライマリデータ]と[レプリカの使用量]と出力されており、ミラーリングされたVMDKファイルの総サイズが8.88GBとなっているのが分かります。
つまり、仮想マシンのサマリ画面から確認できたストレージ使用量は、ミラー化されたディスクの使用量も含まれている状況であった事が分かりました。
このように、vSANデータストアを利用する場合は仮想マシンのディスクサイズがストレージポリシーによってミラー化される為、その点を考慮に入れて仮想マシンを配置する必要があるわけです。
vCSAでのメール通知テスト方法
vCenter Serverで検知するアラームをメールで通知したい場合はSNMPトラップやメール送信などを利用するケースがありますが、今回はアラームを意図的に発報してメール通知を確認する方法と、躓いた点について記事としてまとめます。
環境構成
通知送信元：vCenter Server 7.0 Update2
通知送信先：Windows Server 2016上に構成した SMTPサーバ
※fakeSMTPを使用
FakeSMTP – FakeSMTP - Dummy SMTP server for developers
テスト環境構成
vCenter Server側ではメールサーバとメール送信者を設定します。
今回は[ホストの接続と電源状態]の事前定義アラームを利用する為、メール送信先を設定しておきます。
FakeSMTPを起動し、ポート25でメール受信を待機します。
送信テスト実施
vCenter Server管理のESXiホストをパワーオフし、意図的に応答なし状態とします。
結果として、vCenter Serverはホストと接続できない状況となる為、[ホストの接続と電源状態]のアラームが発報されます。
問題点
ここまでは予定通りでしたが、FakeSMTP側ではメールを受信していませんでした。
VMware KBで該当しそうな以下の対処を実施したものの、解消しない状況でした。
アラート/イベントがトリガーされた後に vCenter Server Appliance からアクション メールが送信されない (54375)
https://kb.vmware.com/s/article/54375?lang=ja
問題個所の確認
vCSAのジャーナルログを見ると、sendmail自体は動作していますが送信先のアドレスが解決できない為に処理が止まっているようにみえます。
Aug 14 09:19:19 vcsa.test.local sendmail[11942]: 17E9JJE9011942: from=send@example.com, size=1075, class=0, nrcpts=1, msgid=<202108140919.17E9JJE9011942@vcsa.test.local>, relay=root@localhost
Aug 14 09:19:19 vcsa.test.local sendmail[11953]: 17E9JJSk011953: ruleset=check_mail, arg1=<send@example.com>, relay=vcsa.test.local [127.0.0.1], reject=451 4.1.8 Domain of sender address send@example.com does not resolve
今回はダミーのメールアドレスを設定しているので、sendmail自体が名前解決を必要としていて、処理が進行していない状況にみえます。
調べてみると、sendmailはメールを送信する際にDNSサーバにMXレコードを問い合わせて送信するようなので、DNSサーバにダミーのドメインが登録されていない事が原因のようです。
回避手段
vCSAのsendmailの設定ファイル sendmail.cf に直接SMTPサーバのアドレスを記述する事で、DNSサーバへのMXレコードの問い合わせを行わないように設定します。
以下の手順でファイルを修正、sendmailを再起動します。
① ファイルの権限を一時的に変更
# chmod 777 /etc/mail/submit.cf
② viエディタで submit.cf の以下を修正し、SMTPサーバのアドレスを追記
---------------------------------------
# "Smart" relay host (may be null)
DS[192.168.1.45]
---------------------------------------
③ ファイルの権限を元に戻す
# chmod 444 /etc/mail/submit.cf
④ sendmailサービスを再起動
# systemctl restart sendmail
結果
再度ESXiホストをパワーオフした際の動作を確認したところ、SMTPサーバ側に
メールが到達している事が確認できました。
所感
躓く点が多かったですが、メール送信テストでDNSサーバの設定変更やレコード登録などは手間がかかります。その為、SMTPサーバのアドレスをsendmail側の設定変更で解消できれば大きな手間は掛からない事がわかりました。
分散スイッチで管理されたESXiホストの削除時のトラブル
分散スイッチ(以降vDSと記載)を利用している場合、全てのvmkernelアダプタをvDS配下に配置して管理を一元化している環境も多いでしょう。
その為、標準スイッチ(以降vSSと記載)はひとつも無いといった構成もありえます。
今回はトラブル発生時に管理用のvmkernelアダプタがvDS配下に紐づいている場合、どうなるかについて確認していきます。
利用する環境は、3台のESXiホストがvDS配下にあるクラスタ構成の環境です。
ホストで障害が発生し、応答なし状態となりました。
障害が復旧するまで、インベントリ上から該当ホストを削除します。
その後、障害復旧した後にホストを再度インベントリに追加すると、サマリ画面に
エラーが表示される状況となります。
これはvCenter Server上からホストのvDSの情報が削除されているものの、ESXiホスト側ではvDSの情報を保持しており、構成不一致と判断され表示されている状況です。
構成上は管理用のvmkernelアダプタがvDS配下に紐づいている為、アダプタの削除もできません。
復旧方法としては、以下のような手順で進めていきます。
1) vmkernelアダプタをvSSに移行
2) vDSにホストを追加
3) vmkernelアダプタをvDSに移行
vSS側の操作で、vmkerenelアダプタをvSSに移行します。
その後、vDS側で対象のホストを選択し、物理NICを指定してホストを追加します。
vDSにアップリンクが追加された事を確認します。
次にvmkernelアダプタをvSSからvDSに移行します。
問題なく管理用のvmkernelアダプタをvDSに戻す事ができました。
結果として、一時退避用のvSSを用意してvmkernelアダプタを移行する事で元の構成に戻すことができました。
vDSを利用している場合、ESXiホストをインベントリから削除すると予期しない問題が発生する可能性があるので、安易に削除しない方が良さそうですね。
iSCSIポートバインドの構成直後の挙動
ESXiホストとiSCSIストレージとの構成で利用されるiSCSIポートバインドの構成について動作を確認する際に疑問点が生じた為、解消方法と共に備忘録として記載しておきます。
想定される挙動
ESXiホストにiSCSIポートバインディングを構成する事で、vmnicとvmkernelアダプタを一対一で紐付けてストレージへの複数パスを利用した冗長性、および負荷分散を実現できます。
ソフトウェア iSCSI とのネットワーク通信設定のベスト プラクティス
ソフトウェア iSCSI ポートのバインド
ESXi ホスト上のソフトウェア iSCSI イニシエータを 1 つ以上の VMkernel ポートにバインドすると、バインドされたポートのみを使用して iSCSI トラ
フィックがやり取りされるようになります。ポートのバインドを設定すると、バインドされたすべてのポートから、設定されたすべてのターゲット ポ
ータルへの iSCSI セッションが iSCSI イニシエータにより確立されます。
設定変更結果
ESXi 7.0上の既存のvSwitch0にiSCSI用のvmkernelアダプタを2つ追加し、それぞれvmnicを一意に紐づけました。
iSCSIポートバインディングの設定後にiSCSIのストレージパスを確認すると、ポートバンドで設定した2つのパス以外にもう1つのパスが表示されています。
「アダプタの再スキャン」や「ストレージの再スキャン」を実施しても、3つのパスがそのまま表示されている状況であり、おそらく既存のvmk0を利用したストレージパスの情報が残存しているものと想定されます。
解消手段
vCenter Server上からの操作だと有用な手段が見つからなかった為、ESXiホストの再起動を実施する事で、ポートバインドで設定した通りに設定した2つのパスのみを利用する状況に変化しました。
所感
iSCSIポートバインドの設定方法や動作などは過去の経験から一通り設定操作は行えるものと思っていましたが、細かい仕様までは情報として抑えきれていませんでした。一連のドキュメントの見直しや動作検証を通して改めて理解を深める事ができた点が有益でした。
esxtopでのオーバーコミット状態の確認
自宅ラボ環境はメモリ16GBの物理サーバ上に3台のNested ESXi 7.0 とvCSA、その他2つの仮想マシンが稼働しています。その為、メモリのオーバーコミットありきで作成した環境でしたが、稼働中にどのくらいの負荷が掛かっているかをesxtopコマンドの結果から見てみました。
なお、物理メモリ 16GB の物理サーバーに以下の仮想マシンを作成、稼働させています。
仮想マシン 仮想メモリ
-------------- --------------
DNSサーバー 512MB
vCSA 12GB
ESXi 3台 24GB(各8GB)
FreeNAS 4GB
esxtopコマンドでメモリパネルより確認します。
「MEM over commit avg」は直近で1.54 となっており、オーバーコミット状態となっています。
その為、仮想マシンの総計が物理ホストのメモリを大きく上回っている為、あまり好ましい状態ではありません。
minfreeは 652MBとなっており、state は「clear」となっています。
minfreeのしきい値に応じて、ESXiホストではメモリの回収が行われる為、
現状TPSによるメモリ回収のみが動作しうる状況です。
State Threshould Action
------- ------------------ -------------------------------------
High minfreeの300% TPSの待機
Clear minfreeの100% TPS
Soft minfreeの64% TPS、バルーニング
Hard minfreeの32% TPS、スワップ、圧縮
Low minfreeの16% TPS、圧縮、スワップ、ブロック
検証利用でしか使わない環境ではあるものの、オーバーコミット状態とせず、かつESXiホストのメモリ回収に頼らずに安定動作するのが本来は望ましいですね。
参考
ESXiのUSBブートのインストーラ作成
現状
ESXiのインストールやVCSAのデプロイなど一通りの検証環境の作成は済んだ為、再構築前提で楽にインストールし直す手段がないか模索している状況でした。
一番のボトルネックが、メディアブートによるESXiインストーラの起動です。
問題点
Optiplx 3020には500GBのSSDとDVDドライブが付いていますが、インストーラ起動の為だけにDVDドライブを付けている状況でした。その為、DVDドライブをSATAのHDDと取
り換えて、仮想マシンやメディア保存用のデータストアにできないか、模索していました。
改善策
ESXiのUSBインストーラをRufusというアプケーションを利用する事で容易に作成、USBブート可能な点を確認しました。
Rufus - 起動可能なUSBドライブを簡単に作成できます
結果、DVDドライブが配置されている場所をSSDと入れ替えて、HDD+SSD構成とする事で、仮想マシンやメディア保存用のデータストアを容易する事ができました。
ESXi 7.0のインストール
環境構成
自宅ラボ環境を作成するにあたり手頃な金額でそれなりに動作するようなサーバー機を探してみて、今回は1万円弱で以下の機器を購入しました。
モデル：Dell Optiplex 3020
CPU ：Core i3 4130 3.4GHz
メモリ：8GB
HDD ：120GB(SSD)
ハードウェアはVMware Compatibility Guide上にリストされていない為、個人利用の責任範疇の構成です。
大型のサーバー機を置くスペースがあまりないので、今回は上記構成を元にメモリ増設、SSD入れ替えで性能拡張します。
メモリ：8GB 16GB
インストール作業
購入したモデルだとオンボードでNICが付いていますが、ESXiインストール時にNICを認識せず「No Network Adapters」と表示されインストール作業が継続できませんでした。
いろいろ調べてみると、オンボードNICで利用するドライバはESXi 7.0でのvmkapiの依存性エラーによりインストール自体ができない状況のようでした。その為、現状ドライバの追加などでは対処できないようです。
ESXi 7.0 のインストールまたはアップグレード中に vmkapi 依存関係エラーが発生する (78389)
https://kb.vmware.com/s/article/78389?lang=ja
その為、追加でIntel製のチップセットが使われている拡張ネットワークアダプタを追加しました。
結果、ネットワークカード側のNICを認識しインストール作業は継続出来た為、ESXi 7.0のインストールも無事完了しました。
