フォワードプロキシを使ってHCLデータベースを更新するには?

CJです。

 

vSAN環境には、HCLデータベースという概念が含まれていること、知っていますか?

vSAN環境は、VMware社がハードウェア・ドライバー・ファームウェアなどの構成を厳しく管理しており、VMware社内でのテストが完了したもののみ、Certifiedされています。

#このような情報は、VMware Compatibility Guide 上から確認できます。

このようなハードウェア互換性の情報はもちろん継続的に更新が行われており、

vSAN内でも継続的に更新される互換性情報が取得される仕組みが入っています。

それが、こちらのHCLデータベースとなります。

こちらのHCLデータベースを更新するには、2つの方法があります。

・手動:ファイルから行う方法

・自動:インターネットから直接更新ファイルをゲットする方法

手動でファイルから更新を行う場合、データソースは以下のURLよりダウンロードできます。

https://partnerweb.vmware.com/service/vsan/all.json

せっかくなので、ダウンロードしたHCL更新ファイル (all.json)の中身をみると、

このように、各ベンダー・ESXiバージョンなどのデータソースが更新されていることがわかります。

これをみると、やはりHCLデータベースはボタン一発の自動更新を行ったほうが当然楽です。しかし、vSphere環境を管理するサーバーのセキュリティを高めるため、直接インターネットに繋がらないように構成して運用するところも多いのではないでしょうか。

この場合は、Proxyサーバーを経由すると効果的です。

また、vSANにもこのようなシナリオにも対応できるように、proxy構成オプションも予め用意されています。 構成イメージは以下のとおりです。

vCenterより、以下の項目で設定が可能です。

クラスタ > 管理 > 設定 > Virtual SAN (全般) > インターネット接続

参考 : vSphere 6.0u3 (vSAN6.2) 環境であり、proxy サーバー(CentOS6)は mod_proxy を使って事前にフォワードプロキシ設定が済んでいる状態です。

設定しておいた Proxyサーバーのホスト名およびポート番号を入力してください。

設定したプロキシサーバーの情報が反映されていることがわかります。

vSphere環境上での設定はこれで終わりです。とても簡単ですね。

では、早速自動更新をクリックして、プロキシサーバーHCLデータベースの更新リクエストが来ているかを確認しましょう。

# tail -f /var/log/httpd/access_log

きちんとプロキシサーバーにリクエストが来ていることがわかります。

また、更新ファイルも手動でダウンロードする URLと同じであることがわかります。

念のため、エラーログは出てないかを確認しましょう。

なんと、このようなエラーが出ています。

Response header ‘Set-Cookie’ value of ‘___utm…省略..’ contains invalid characters, aborting request

Set-Cookieの値に、有効ではない文字が入っているようで更新ができなかったようです。

今回、HCLデータベース更新が目的なので、特に Set-Cookie は気にせず無効にすることに。

# vi /etc/httpd/conf/httpd.conf

Header unset Set-Cookie

これで、再度HCLデータベースの更新を実行すると、Proxyサーバー側にリクエストも来ており、エラーも出ず、正常にHCLデータベースが更新されたことが確認できました。

 

以上、同じく Proxyサーバー経由でかつ Response heade 問題で引っかかっている方がいれば、本記事が少しでも役に立てれば嬉しいです。

 

[参考情報]

Updating the vSAN HCL database manually (2145116)
https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2145116

 

vSAN環境で L3-vMotion を行うには?

CJです。

vSphere 6環境において L3経由での vMotionが行えること、知っていますか?

構成によって、L3 vMotionを使用するケースもあると思います。

今回はそういったことが、実際可能かどうか、せっかくなので vSAN環境上で試した結果を共有したいと思います。

 

まず、想定している検証の構成は以下のとおりです。

今回、表側の分散スイッチ経由で vMotionを行うテスト内容となります。合わせて dvPort は予め作成されていることを前提としています。

環境構成

・vCenter 1つの配下に、CLUSTERが 2つ(AとB)存在し、各クラスタは vSAN構成が有効になっています。

・CLUSTER_A(vSAN)上で動いている仮想マシン(CJ_VM01)が、L3経由で CLUSTER_Bへ vMotionを行います。

・L3は vyOSを利用します。

・Version 情報: vSAN 6.2、CentOS6 (CJ_VM01)、vyOS(1.1.7)

 

 

では、早速各パーツごとに設定を見ていきましょう。

仮想マシン (CJ_VM01)

普通にネットワークインターフェースに適切な IPアドレスの設定を行う。

クラスタA側のvyOS (CJ_vyOS1)

各インターフェースの設定を行い、その後スタティックルーティングを行う。

#vyOS設定後、#commit と #save も忘れずに~ (ここでは省略しています。)

クラスタB側のvyOS (CJ_VYOS2)

構成に合わせて各インターフェースの設定を行い、その後スタティックルーティングを行う。

VMkernelの追加 & TCP/IP スタック (vSphere)

vMotion用の VMkernelアダプタを両クラスタの各ESXi に追加する。

TCP/IP スタック設定で、vMotion 用 VMkernel のゲートウェイの設定を行う。

TCP/IP スタック (vMotion) に、IPv4 ゲートウェイが設定されていることがわかります。

これで、設定は完了です。 後は移行(vMotion)を試してみてください。

自分のテスト環境においては、vSANデータストアの移行を含め、仮想マシンが正常に vMotionができることが確認できました。

 

普段、vSphere 環境で vMotionは L2接続状態の環境で使うことが多いかと思いますが、移行のシナリオなど各自の状況によっては L3を経由するシナリオが出て来るかもしれないです。その際には、本記事が少しでもお役に立てればと思います。

 

[参考情報]

ESXi ホストの vMotion TCP/IP スタックへの vMotion トラフィックの配置
https://docs.vmware.com/jp/VMware-vSphere/6.0/com.vmware.vsphere.vcenterhost.doc/GUID-5211FD4B-256B-4D9F-B5A2-F697A814BF64.html

Configuring the vMotion TCP/IP Stack for Layer 3 vMotion Across ESXi Hosts

Configuring the vMotion TCP/IP Stack for Layer 3 vMotion Across ESXi Hosts