VCS to VCSA : Windows版 vCenter から 仮想アプライアンス版 vCenterへの移行手順

CJです。

多く使われている Windows版 vCenter Server (以下、VCS)も次期 vSphereバージョンからはサポート外になるようです。現在、仮想アプライアンス版 vCenter Server (以下、VCSA)ではほとんどが VCSと変わらず使える状態ですが、マルチNICが正式サポートされていなかったり一部もの足りないところもあるのが現状です。しかし、いつか VCSAになること、ライセンス節約の観点からのメリットもあるので、各自の状況に合わせて移行をご検討いただければと思います。

今回は、この移行方法についてスクリーンショットとともに流れを共有したいと思います。

移行環境

VCS:Windows Server 2012 R2 / PSC組み込み / 別途 DBサーバー(SQL server)が存在 / vCenter 6.0 U2

VCSA: vCenter 6.5 U1

Client: Windows Server 2012 R2

移行イメージ図

移行手順

VCSAデプロイ手順

1.VCS上に、VCSA isoファイルより、”migration-assistant” フォルダをコピーし、VMware-Migration-Assistant アプリを実行する。

Tip: 移行前に、以下の内容を確認してください。

・DRS 無効化 / NTP 同期 / Default Gateway 設定 / もし、iptables 制御している方はそちらも要確認

2.Client PC (以下、Client) に、VCSAの isoファイルをマウントしてインストールファイルを実行。”CDROM : vcsa-ui-installer\win32\installer.exe”

3.移行を選択

4.VCSAのデプロイ / 次へ

5.エンドユーザー使用許諾契約書 / 同意にチェックを入れて 次へ

6.VCSの情報を入力して、次へ

サムプリントの検証画面が表示されたら、”はい” をクリック

7.デプロイ先の ESXi or vCenter 情報を入力 (ここでは ESXi 情報を入力しています。)

証明書に関する警告画面が表示されたら、”はい” をクリック

8.VCSA名と root パスワード情報を入力して、次へ

9.各自の環境に適した VCSAのサイズを選択して、次へ

10.データストアを選択して、次へ

11.ネットワーク構成情報を入力して、次へ

12.設定内容の確認ページが表示されるので、確認後問題なければ “終了” ボタンをクリック。そうすると、初期化された後デプロイが開始されます。

13.デプロイが完了されたら、次は VCSAへ接続します。

https://[VCSAのIPアドレス]:5480

ちなみに、デプロイされた VCSAのディスク構成はどうなっているでしょう。

小 (4 vCPU、16GB RAM)サイズでは、以下の構成となっていることがわかりました。

VCSA への移行手順

1.”Windows 上の vCenter Server インスタンスからの移行” を選択

2.上記手順 8 で設定した VCSAの root パスワードにてログイン

3.ステージ1が終わっている状態で、ステージ2になることを確認の上、次へ

4.VCSの情報を入力して、次へ

証明書に関する警告画面が表示されたら、”OK” をクリック

5.VCS上では、以下のように事前チェックが走っていることがわかります。

暫くすると、移行前チェックの結果が表示されます。

今回、VCS上では VMware Update Manager (以下、VUM)が使用中だったための警告が表示されていますが、スキップします。”閉じる”をクリック。

6.今回の移行では、設定のみ移行すればOKということで、次へ

7.CEIP 参加可否の画面が表示されますが、ここではチェックをOFFにして、次へ

8.設定の確認画面が表示されます。”ソースの vCenter Server をバックアップしました” のチェックボックスにチェックを入れて、終了。

シャットダウンの警告が表示されるので、”OK” をクリック。

VCSAは基本 VCSの情報を引き継ぐため、同一セグメントに置かれている VCSを起動前に止める動きとなっています。

9.VCSから VCSAへデーターコピーが行われます。(vSphere Web Client データのエクスポートなど)

10.VCSA の設定が行われます。

11.すべてのデーターが VCSAへインポートされてから、完了となります。

12.もし、以下のようなエラーが表示されたら、ブラウザのキャッシュをクリアしてみてください。

13.移行完了。

正常に vCenter 6.5 になっていることがわかります。

 

思ったより簡単に移行できそうではないでしょうか。

ぜひ、お試しください。

VCS (シャットダウン中)はそのまま残っている状態のため、もし移行が何らかの理由で途中失敗した場合でも簡単に切り戻しができるのもチャレンジしやすいところかと思います。

 

Tip:VCSでローカルアカウント設定を行っている場合は、移行前にユーザー権限を外してください。そうしないと、移行手順 9 のところ (vPostgres SQLあたり)で失敗する可能性があります。

 

[参考情報]

既知の制限事項

https://docs.vmware.com/jp/VMware-vSphere/6.5/com.vmware.vsphere.upgrade.doc/GUID-5E19B79A-AE4F-497A-9047-3E9AAC1D7767.html

vExpert 2018をいただきました。

CJです。

今朝の発表で、vExpert 2018をいただきました。

個人的には今まで取得してきた資格とは違う性質のもので、非常に光栄であり・嬉しく思っております。これからも得た知識・経験を極力わかりやすい形でシェアしていきたいと思います。

よろしくお願いします。

vSphere6.5環境で、データストアにファイルアップロードができない場合は?

CJです。

vSphere環境上、ISOファイルなどで仮想マシンを作成する場合、まずは ISOファイルをデータストア上にアップロードするかと思います。今まで (vSphere 6.0以下)は、普通にデータストアを参照して、ファイルのアップロードが簡単にできたと思いますが、vSphere6.5では、以下のようなエラーと共にアップロードに失敗することがあるようです。

今回は、このようなエラーに対する対策について共有したいと思います。

原因

今まではブラウザ側で vCenterサーバーの証明書を信頼するだけで十分だったのが、
vSphere6.5では、vCenter Serverの自己証明書が証明書ストアの “信頼されたルート証明機関”にないと、vSphere Web Clientが、vCenter Server とファイルを共有できない・仕組みの変更があるようです。

対策

以下の手順(例.Windows Server)にて、vCenter Serverの自己証明書を “信頼されたルート証明機関” に追加さればOKです。

1. vCenter Server [https://vCenter Server] へ接続し、右下の “信頼されたルート CA 証明書をダウンロード” をクリック

2. ダウンロードしたファイルを展開し、セキュリティ証明書をダブルクリックする

3. 証明書のインポートウィザードより、ローカルコンピューターを選択して次へ

4. 信頼されたルート証明機関を選択

5. 完了

6. 確認

 

[参考情報]

Uploading files to a vSphere service might fail (2147256)

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

vCenter Server ルート証明書をダウンロードしてインストールして、Web ブラウザ証明書の警告を防ぐ方法 (2148936)

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

vSphere 6.5 – Unable to upload files to Datastore or deploy OVAs

vSAN環境において異なる機種の混在は可能なのか?

CJです。

vSAN環境は安定したパフォーマンスを出すため、基本的に同一のもの (ハードウェア、vSphere version/build など) を使うことを推奨とされているようです。

しかし、使用中のハードウェア(Server)・ドライブ(SSD)が生産終了などを向かえ、購入できない状態になったらどうなんでしょうか。 やはり、ユーザーとしては安定した性能・サービスを使い続けたいわけです。

気になるこの問題について、確認してみました。

結論から言うと、混在は可能です!

VMwareさんの storagehubサイトに上記のような内容が掲載されています。

基本、VMware Compatibility Guideに登録されているものであれば、混在は可能です。ただし、注意事項としては 性能のばらつき・EVC対応可否によっては vMotionができなくなるなどのこともおきうるので、十分ご検討の上で進めてもらったほうが良いかと思います。

[参考情報]

vSAN FAQ > Architecture

https://storagehub.vmware.com/t/vmware-vsan/vsan-frequently-asked-questions-faq/architecture

Enhanced vMotion Compatibility (EVC) processor support 

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

PowerCLI : VMが稼動しているホスト情報を確認するには?

CJです。

vSphere 基盤を運用していると、以下のケースにおいて簡単な情報を素早く確認したい時があります。

・特定のホスト上で稼動している VM リストを確認

・VMが稼動中のホストを確認

もちろん、このような情報は GUI (vSphere Web Client) 上からも確認は可能ですが、VM数が数百台の規模とかになると、やはり確認に時間がかかったり、GUI操作に不便を感じるかと思います。その際にはぜひ以下の PowerCLI コマンドを試してみてください。

テスト環境

VMware PowerCLI 6.5.1 build 5377412 です。

Get-PowerCLIVersion

特定のホスト上で稼動している VM リストを確認

 

少し工夫して “host1.cjnotes.com”ホスト上で稼動しているVMで、電源ONかつVM名に “CJ” が入っているVMリストを確認してみます。

Get-VM | Where {$_.Name -eq “host1.cjnotes.com”} | get-vm | Where {$_.PowerState -eq “PoweredOn” -and $_.Name -like “CJ*”} | sort

すると、このようにVM情報が簡単に確認できます。

VMが稼動中のホストを確認

こちらも同じくVMが電源ONであり、VM名に “CJ” が含まれているVMリストのホスト情報を確認してみます。

 

Get-VM | Where {$_.PowerState -eq “PoweredOn” -and $_.Name -like “CJ*”} | sort | select Name,PowerState,VMHost

すると、このように各VMが稼動中のホスト情報も確認できます。

 

 

今回は割愛させていただいていますが、上記コマンドを CSVファイルなどへエクスポートすることも可能です。 メンテナンスなど、作業前後の状態を取得するケースでも有効なコマンドかと思いますので、ぜひお試しください。

ESXiバージョン別の vSAN 性能を比較してみると?

CJです。

vSANは基本 ESXi バージョンアップに合わせて、様々な改善が行われます。

今年2月にも ESXi 6.0U3がリリースされ、以下のような vSAN性能改善が行われたことが知られています。

Virtual SAN のパフォーマンス:VMware ESXi 6.0 Update 3 リリースでは、I/O パスの最適化を実現するため、複数の修正が加えられています。これにより、オール フラッシュ構成およびハイブリッド構成の Virtual SAN のパフォーマンスが向上します。

リリースノートのこの文面だけでは、実際どれくらい性能が向上されたかがわかり難かったため、性能測定を行い、その結果を共有したいと思います。

テスト環境

いつもの大好きな RAID-6 (Erasure Coding) の vSAN環境となります。

性能測定方法

fio を利用して性能測定 (IOPS)

#同一条件で行ったため、細かいパラメータはスキップします。

テスト結果

1プロセッサーの場合 (1P)  / 4プロセッサーの場合 (4P)

いかがでしょうか。

リリースノートに書いてあったパフォーマンス向上の話は本当であり、かつ1行の説明で終わっているような感もしますが、実は測定結果の通りに大きな改善がありました。念のため、現時点の最新バージョンである ESXi 6.5U1 と比較してもそれほど変わらないこともわかります。これから vSANの使用をご検討の方、ESXi 6.0U3 より前のバージョンを使っている方はぜひ ESXi 6.0U3 以上の使用をご検討いただいたらいかがでしょうか。

 

vSAN 仮想マシンの容量が増えるにつれ、ObjectとComponentに起きる変化とは?

CJです。

先日、vSAN環境における RAID-6 にて “VM、Object、Components” の全体的な概要について共有しました。 今日は、その延長となる内容で実際仮想マシンのデータが増えるにつれ、VMの構成要素でもある Object と Component がどのように動作していくのかについて共有したいと思います。

では、早速確認していきましょう。

まず、検証環境はいつもの大好きな RAID-6 構成 (vSAN 6.2) となります。

 

VM作成前

vsan.obj_status_report /localhost/DCNAME/computers/CLUSTERNAME

RVC上で、こちらのコマンドを実行し、まず VM作成前の Object 数を確認してみました。

本環境には、現在 1 Object が存在し、その Object に 6 Components が存在しているのがわかります。 まだ本環境には VMが1台も存在していないのに、なぜか 1 Objectがすでに存在する状態です。 この 1 Object は vSAN 健全性とパフォーマンスオプションが有効になっていると vsanDatastore上で vsan.statsフォルダができますが、これの Object となります。

次は、1TBのディスク容量を持つ VMを作成してみました。

VM作成 (1TB / Thin)

すると、GUI (vSphere Web Client) 上からは、以下の通りに表示されていることがわかります。

#Object : VM ホーム

#Object : ハードディスク (VMDK)

CUI (RVC) からは、以下の通りに表示されます。

vsan.vm_object_info localhost/DCNAME/vms/VMNAME/

GUI上で表示されていた “VM ホーム” と “ハードディスク” のコンポーネント詳細が表示されます。また、こちらで各コンポーネントの容量も確認できます。

vsan.obj_status_report /localhost/DCNAME/computers/CLUSTERNAME

Object Status Report からも、VMDKや VMホームのコンポーネントが表示されたことがわかります。ところが、RAID-6なのになぜか 1 Object に対して 3 Components になっているものが存在しています。これは、VMを起動すると現れる SWAP object となります。 SWAP object は特別扱いで RAID-6 構成であっても、RAID-1の動き (1 コピー + 1 Witness) をするみたいです。

ここまでの整理

ここまでの状況を簡単に整理すると、以下の通りとなります。

VMを作成すると、

・3つの Object (VMDK、VMホーム、SWAP) ができ、

・各 Object はさらに Component に分割され、

・Componentは VMDKが12個、HOMEが6個、SWAPが3個

であることがわかりました。

VMDKの Component 数は、なぜ 12個?

vSAN仕様上、1つの Object は Component で構成されており、1 Component の最大サイズは 255GB となっています。

今回、1TBディスク (データ) を持つ、VMを作成しましたことを思い出してください。

1TB = 1024GB ですね。

255GB x 4 (Component : データ) = 1020GB となります。

この 1020GBをオーバーするため、不足している分 (1021~1024GB) の Component が増加 (6つ)する動きとなっています。

これを簡単な図で表したのが、次です。

仮想マシンの容量が増えるにつれ、Component のサイズはどうなるの?

仮想マシンの容量が増える (Guest OS 内のデータが増える)と、VMDK Object を構成している各 Component のサイズも均等に増加します。実際、Guest OS内のデータを増やして行く際の Component サイズの変化を表したのが、次です。

各 Component の容量が 127.5GB で均等に分散されているのがわかります。

また、vSANのRAID-6を使う場合に、ディスク使用量が 1.5倍になりますが、きちんと仕様通りの動きになっていることもわかります。#1530GB

Tip: 2TB のVMを作成すると?

Componentの数と容量が増えていることがわかります。

まとめ

いかがでしょうか。

VMの構成要素 (Object & Component) とそれらの増加タイミング、数、容量などの変化が起きる仕組みがお分かりになりました?vSAN ならではの仕様でもあるため、なんとなくわかっても綺麗に整理できなかった方々に本記事が少しでも役に立てればと思います。

 

[参考情報]

SWAP Object について

http://www.yellow-bricks.com/category/storage/page/2/

vSAN Objects and Component Placement

Understanding vSAN Rebuilds and Repairs

vSAN 暗号化機能を使うには?

CJです。

 

vSAN6.6で新たに暗号化機能が追加されたこと、知っていますか。

vSANでは、2つタイプの暗号化機能が追加されています。

そのひとつ目は、仮想マシンストレージポリシーを使って VMごとに適用することができる ” VM 暗号化”、二つ目は、トランジットが発生していない時に vsanDatastore 全体を暗号化する “vsanDatastore 暗号化” です。

今日はそのうち vsanDatastore 暗号化機能をどうやって有効化するかについて共有したいと思います。

テスト環境情報

・vSAN 6.6.1 (ESXi 6.5 U1)

・Key Management Server (以下、KMS): HyTrust KeyControl

 

1. まずは、VCGの確認から

暗号化機能を使うためには、KMSサーバーが必須となります。

もちろん、vSAN環境なので既存のパーツと同じく、KMSサーバー自体も VCGにて管理されています。 このリスト上に掲載されているものからお使いください。

自分は、VMworldなどでも紹介されたりした HyTrustさんの KMSサーバーを使うことにしました。

2. KMSサーバーのデプロィ

vCenter と同一のネットワーク上に、KMSサーバーをデプロィします。

HyTrustさんからは、OVA 形式で仮想アプライアンスが提供されており、自分はこちらを使っています。#ISO形式でも提供されています。

また、KMSサーバーのシステム要件としては Standard基準として以下が求められています。

・2cpu / 8GB RAM / 20GB HDD

このように、必要なパラメーターを入力して、KMS仮想アプライアンスをデプロィします。

3. KMSサーバーの構成

vCenter (Windows版)より、HyTrust KMSサーバーへIEより接続します。

初回はデフォルトの “secroot / secroot” にてアクセス可能です。

ログイン直後に、パスワード変更が求められますので、パスワードの更新を行ってください。

KMIP構成画面より、Stateの有効化および VCGに掲載されていた Versionに合わせて設定を行います。

KMIP構成後は、Users > Create User にてユーザーを作成してください。

※本手順ではユーザーのパスワード入力なしにしてあります。

ユーザー作成後は、Actions > Download Certificate にて証明書を保存してください。後ほど vCenter にKMSサーバーを登録する際に使います。

保存した zipファイルを展開すると、上記のように2つのファイルがあります。

このうち、後ほどvCenter側で使うのは左側のファイル (KMIPUser.pem)となります。

4. vCenter に KMSサーバーを登録

KMSサーバーの準備ができたため、次は vCenterサーバーに KMSサーバーの登録を行います。 vCenter > 設定 > 詳細 > キー管理サーバー > KMSの追加

この後、引き続き信頼の確立を行い、”証明書およびプライベートキーのアップロード”を選択してください。

証明書とプライベートキーをアップロードするところが表示されたら、事前に保存しておいたユーザー証明書・キーファイル (KMIPUser.pem) をアップロードしてください。

証明書登録後も、接続状態が “正常” にならない場合があります。

※その際は、”すべてのアクション”メニューより、証明書の信頼アクションを実施すると改善されます。

5. vSAN 暗号化の有効化

これですべての準備が完了しました。

最後は、vSANクラスタの暗号化機能を有効にするだけです。

クラスタ > 設定 > vSAN > 全般 > vSAN設定の編集 > 暗号化 : チェックイン

そうすると、ディスクフォーマットが動作し、ディスクグループの再作成が行われます。

終わった後は、以下の通りに暗号化機能が有効になっていることがわかります。

ちなみに、vsanDatastore の暗号化によるパフォーマンス影響はほとんどないようです。

#CPUの負荷としては、5~15%程度。

まとめ

いかがでしょうか。

上記の4ステップだけで、vSAN 暗号化機能が簡単に使えるようになります。

既存のハードウェア製暗号化ソリューションに比べて、vSAN上で簡単な設定を行うだけで、セキュリティを高めることができるのはとても嬉しいです。

ぜひ、一度 vSANの暗号化機能をお試しください。

※KMSサーバーおよび vSAN暗号化を有効にするためには、それぞれに該当する適切なライセンスを購入・適用してください。詳しくは各KMSベンダーへお問い合わせください。

 

[参考情報]

vSAN クラスタでの暗号化の使用

https://docs.vmware.com/jp/VMware-vSphere/6.5/com.vmware.vsphere.virtualsan.doc/GUID-F3B2714F-3406-48E7-AC2D-3677355C94D3.html

HyTrust KeyControl with VMware vSphere VM and VSAN Encryption

https://docs.hytrust.com/DataControl/Admin_Guide-4.0/Default.htm#Books/VMware-vSphere-VSAN-Encryption/aaTitle-KeyCtrl-for-vmware-encrypt.htm%3FTocPath%3DHyTrust%2520KeyControl%2520with%2520VMware%2520vSphere%2520VM%2520and%2520VSAN%2520Encryption%7C_____0

 

 

vSAN のバージョンを確認するには?

CJです。

vSAN環境を運用していると、使える機能や制限事項などの確認のためにバージョン情報を確認したくなる場合があります。その際に有効な確認方法を共有したいと思います。

バージョンの考え方

vSANはHypervisor (ESXi) に予め組み込まれているもののため、基本的な考え方としては ESXi バージョンによって vSANのバージョンも変更される形になります。 イメージとしては以下のとおりです。

 

とてもシンプルでわかりやすい考え方だと思います。

# vSANバージョンごとの機能の違いはこちらの記事を参考にしてください。

vSphere 環境上での確認方法

では、実際 vSphere Web Client または PowerCLI などで明確にバージョンを確認する方法はないか気になる方もいると思います。 確認方法はあります。

まず、GUI (vSphere Web Client) 上では、クラスタ画面上でも、ホスト画面上でも特にvSANのバージョン情報は見当たらなかったです。個人的にはクラスタ or ホストのサマリページに表示されたら嬉しいと思いますが、とにかくないようです。

#もし、GUI上での確認方法がわかる方はお知らせください。

念のため、esxcli コマンドにても確認してみましたが、やはり明確な vSANバージョンは確認できないようです。

esxcli system version get

色々調べてみると、VMware社の社員である “William Lam”さんが、PowerCLIで確認できるスクリプトをすでに作成し、配布していましたのでそちらを使います。

#Thanks @lamw

早速、該当スクリプトファイルをダウンロードし、ローカルに配置してください。

自分の環境は Windows Server のローカルドライブ(D:)に配置しておきました。

次は、PowerShellを起動して、配置しておいたスクリプトをインポートします。

Import-Module -Name “D:\CJ\VCESXivSANBuildVersion.ps1”

そうると、モジュールがインポートされ、”Get-VSAN タブキー入力” で Get-VSANversion というコマンドレットが表示されることがわかります。これでバージョン確認の準備が完了しました。

実際、”Get-VSANversion” コマンドレットを使うために、vCenterサーバーへアクセスします。 #こちらのテスト環境では、localhost 指定にしています。ご自身の環境に合わせて適切に変更してください。

Connect-VIServer -Server localhost

では、早速スクリプトを実行してみましょう。

Get-VSANversion -ClusterName vSAN-CJ

きちんと、想定していた vSANの明確なバージョン情報が確認できました。

ちなみに、スクリプトの中身にも書いてありますが、こちらのバージョン情報は VMwareKBで公開されているバージョン情報をソースとしてあります。

また、本スクリプトは vSANだけではなく、ESXiやvCenterのバージョン情報も確認できますので、必要に応じて活用してみてください。

 

[参考情報]

PowerCLI script to help correlate vCenter, ESXi & vSAN build/versions w/o manual VMware KB lookup

PowerCLI script to help correlate vCenter, ESXi & vSAN build/versions w/o manual VMware KB lookup

Github:lamw/vghetto-scripts/powershell/VCESXivSANBuildVersion.ps1
https://github.com/lamw/vghetto-scripts/blob/master/powershell/VCESXivSANBuildVersion.ps1

Build numbers and versions of VMware ESXi/ESX (2143832)
https://kb.vmware.com/selfservice/search.do?cmd=displayKC&docType=kc&docTypeID=DT_KB_1_1&externalId=2143832

Build numbers and versions of VMware vCenter Server (2143838)
https://kb.vmware.com/selfservice/search.do?cmd=displayKC&docType=kc&docTypeID=DT_KB_1_1&externalId=2143838

Build numbers and versions of VMware vSAN (2150753)
https://kb.vmware.com/selfservice/microsites/search.do?cmd=displayKC&docType=kc&externalId=2150753&sliceId=1&docTypeID=DT_KB_1_1&dialogID=460798501&stateId=1 0 460808158

フォワードプロキシを使って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