ゲストOS（CentOS7）がインターネット接続できないときの対処法

背景

VMware Workstation Playerにて仮想マシンを作成しネットワーク設定を行ったが、ゲストOSからインターネットに接続することができない、「サーバーが見つかりません」と表示される。勿論Pingによる疎通確認も不可。

環境

• ホストOS：Windows7 Professional version6.1
• VMware Workstation 15.0.2 Player for Windows 64-bit 
• ゲストOS：CentOS7.6

原因

仮想マシンのネットワーク接続をNATに設定し、ホストOSが使用しているWIFIのインターネット共有をVMnet8に対して有効にしていたが、VMwareの設定ファイルに記載されたIPアドレス帯域とVMnet8に自動設定されたものと異なっていた。

※NATとは

ホストのIPアドレスを共有して使用する

解決策

①VMwareの設定ファイルのIPアドレスを確認する。

設定ファイルパス：「C:\ProgramData\VMware\vmnetnat.conf」

#NAT gateway addressのIPアドレスを控える。

②ホストのネットワーク接続からVMnet8のIPアドレスを固定する

ホストのネットワーク設定は、Windowsキー+Rから「ncpa.cpl」で開くことができる。

vmnetnat.confの#NAT gateway addressに記載されたIPは/24であるため、第4オクテットを任意の数字に固定する。

ゲートウェイは第4オクテット「2」で指定し、DNSはGoogleのパブリックDNSにした。

③仮想マシンのIPアドレスを固定する

仮想マシンの端末を起動し、nmcliコマンドにてIPアドレス、DGW、DNSを指定する。

※上記で固定したIPアドレスとは異なるものにすること。

IPアドレス・サブネット変更

nmcli c modify インターフェース名 ipv4.addresses xxx.xxx.xxx.xxx/24 

DGW変更

nmcli c modify インターフェース名 ipv4.gateway xxx.xxx.xxx.xxx

DNS変更

nmcli c modify インターフェース名 ipv4.dns xxx.xxx.xxx.xxx

インターフェースを再起動

nmcli c down インターフェース名; nmcli c up インターフェース名

設定内容を確認

nmcli d show インターフェース名

ネットワーク再起動
systemctl restart network

④Pingで疎通を確認する

どこでもよいが、今回はyahooのサイトにPingが通るか確認した。

ping www.yahoo.co.jp

参考文献

VMware VMnet8（NAT）でネットワーク設定したのでメモ - あとらすの備忘録

ゲストのCentOS7からインターネット接続する方法(NAT) - Qiita

centos7 ネットワーク設定 - Qiita

Veeam9.5でバックアップ時にパケロスが生じている話２

VeeamでVMのバックアップを実施すると通信断が発生している件の続き。

akng-engineer.hatenablog.com

VMのバックアップの同時実行数を数個単位で行うと特に問題は発生していないが、2桁のVM数になると、パケロスが生じ同時実行数が増えるほど通信断の時間が長くなっていくことが明らかになった。

今回、１０、１５、２０VMに分けて検証をしたので、その結果についてまとめてみる。

環境

• ESXi6.0　（サーバ：36CPU, メモリ512GB, サイズ446GB） 
• VCSA6.0
• Veeam backup & replication 9.5
• VMバージョン：11
• ゲストOS：Windows server 2012R2

VMスペック

• CPU：2
• メモリ：4GB
• ハードディスク：50GB

結果

フルバックアップの場合

	Ping断
同時実行数	範囲	平均値	中央値
10	-	-	-
15	0-19	12	12
20	4-28	12	11

 平均値と中央値を見ると15VMと20VMでは大差ないが、Ping断の数で見ると15VMより20VMのほうがPing断が発生する頻度が高くなった。

差分バックアップの場合

	Ping断
同時実行数	範囲	平均値	中央値
10	-	-	-
15	8-25	13	12
20	13-50	25	22

 差分バックアップだと15VMと20VMではPing断が発生する頻度に明らかな違いが表れた。平均値・中央値で見ても15VMの約2倍のパケロスが生じていた。

また、フルバックアップと差分バックアップで比較してみても、同時実行数が同じでも差分バックアップのほうがPing断が発生する数が多かった。差分バックあっぷはより負荷が高いのではないかと考えられた。

差分バックアップの負荷が高い理由

差分バックアップはストレージをより効率的に利用するためには最適な方法であるが、ストレージI/Oの負荷が増分バックアップと比較して約3倍高い負荷がかかるため、Ping断が多く発生していると考えられる。差分バックアップは、過去に取得したフルバックアップファイルに対してデータをマージさせる工程があり、その際に高負荷になっているのではないかと推測している。

チーム内ではファイルストレージを使用しているため通信断が起こりやすいのではないかと考えているが、まだ確信を得てはいないので引き続き検証が必要である。。。

ESXi管理コマンドの復習（esxtop, esxcfg-route)

今年初めからインフラ業務に携わり、学んだことが多くあったので今月はその復習をしていきたいと思う。

今回はESXiのコマンド２つについてまとめた。

esxtopコマンド

ESXiのパフォーマンスを測定するコマンド。topコマンドと似た様なもの。

オプション

• -v：バージョンを表示する
• -b：バッチモードを有効する
• -l：esxtopオブジェクトをロックする
• -s：セキュアモードを有効にする
• -a：全統計を表示する
• -c：esxtop設定ファイルを指定する
• -R：リプレイモードを有効にする
• -d：取得間隔を指定する
• -n：取得回数を指定する

キー

esxtopコマンド実行後に押下する

• c：CPU情報を表示する
• m：メモリ情報を表示する
• d：アダプタ単位のストレージ詳細を表示する
• u：デバイス単位のストレージ詳細を表示する
• v：VM単位のストレージ詳細を表示する
• n：NW情報を表示する
• i：割込み頻度を表示させる
• p：CPU消費電力等を表示させる

使用用途

esxtopコマンドはESXi構築後の単体試験のために、esxtop→nを押下しNW情報を見ながら使っている。

データ用vSwitchの冗長性が保たれているか確認するために、2つあるvmnicのうち使用しているvmnicをUnusedにして片側のvmnicに切り替わるかどうか試験している。

esxcfg-routeコマンド

VMkernelポートの固定ルートを構成するために用いる。

オプション

• -a：VMkernelにルートを追加する
• -d：VMkernelからルートを削除する
• -l：VMkernelに設定されたルートを表示させる
• -f：アドレスファミリを指定する
• -r：ルート設定を元の値にリストアする
• -n：ネットスタックインスタンス　※esxcfg-route -f V4 -nでIPv4の近隣キャッシュを見ることができる

使用用途

ESXiにスタティックルートを追加するときに使用している。

私はesxcfg-route -lコマンドで現在のルートを確認し、esxcliコマンドでルートを追加している。

ESXi5.5以降はesxcliコマンドでルート追加することを推奨されているらしい？

esxcli network ip route ipv4/v6 add --gateway x.x.x.x --network x.x.x.x/x

 ルートを追加したら再度esxcfg-route -lコマンドで追加ルートが表示されるか確認し、pingで宛先アドレスに疎通が取れたらおっけー。

参考文献

https://kb.vmware.com/s/article/2092740

Veeam9.5でバックアップ時にパケロスが生じている話

VMのマイグレーションやバックアップをするときにVeeam backup & replication9.5を使用している。ESXiのストレージとしてNFSをマウントしているけど、20個分のVMバックアップを同時実行すると、ジョブが完了する直前にパケロスが生じてるっぽい。（約50秒くらい）

何でか追及してると、バックアップジョブを完了する前に取得したスナップショットを削除するときにI/O負荷が高くなるため、一時的にVM通信が途切れているらしい。

環境

• Veeam backup&Replication 9.5
• ESXi6.0
• vCenter Server Appliance6.0
• Windows Server 2012R2

VMとVMDKファイル

Veeamでバックアップやレプリケーションを実施するときに知っておきたいのは、VMとVMDKファイルの関係についてである。

通常のVMは、変更が生じた場合はVMDKファイルに書き込みを行なったり、何か呼び出す場合はVMDKファイルから読み取ったりしている。

しかし、Veeamでバックアップ・レプリケーションジョブを実行開始すると、ジョブが完了するまでdeltaファイルに変更点が書き込まれ、VMDKファイルは読み取り専用になる。

Veeamバックアップ時の仕組み

また、Veeamのジョブが開始するとまずVMのスナップショットを取得し、ジョブが完了する直前にスナップショットを削除する工程がある。

特にスナップショットを削除するときVMにかかる影響がかなり大きいと言われている。何故なら、ジョブ実行中にVMの変更点が書き込まれているdeltaファイルの中身をVMDKに反映させる操作の際にI/O負荷が大幅に増加するからである。

VMにパケロスが生じた時間のVeeamログを見てみると、ちょうどスナップショットを削除しているときと一致していた。Veeamログの内容は以下の通り。

[dd.mm.yyyy hh:mm:ss] <78> Info [VimApi] Remove Snapsot.type "Virtual Machine Snapshot", ref "snapshot-xxxx", removeChilren "False"

[dd.mm.yyyy hh:mm:ss] <78> Info [VmSnapshotTracker] Snapshot id: "snapshot-xxxx" closed

このログからVeeamがAPIでvCenterにスナップショット削除を命令していることが読み取ることができる。

※RemoveChildren：スナップショットのサブツリー削除を示すフラグ

まとめ

10VM同時実行したときは特にPing断することなくバックアップを完了することができていたが、20VMだと不安定になってしまった。

ブロックストレージをマウントしているときはどうかはまだ検証していないので分からないが、バックアップ同時実行数を増やしても問題ない実績はVeeam側にあるらしいので、VMかストレージのスペック問題な気がする。高価ないいやつにすればパケロスも生じないのかもしれない。