VMware 認定資格の有効期限(2年)が解除?

CJです。

VMware にはVMware Certified Professional (以下、VCP) などの認定資格があり、この資格を有効の状態に維持するためには、2年以内に再認定 (再受験必要)を受ける必要がありました。

ところが、この再認定ポリシーが昨日より変更されたようです。

■再認定ポリシーからの抜粋

As of February 5, 2019, VMware certifications do not have a mandatory recertification requirement.

すでにVCPの更新に間に合わなかった方も、以下のような一定条件を満たせば、2019年4月に有効状態に戻り、最新バージョンの資格更新へトライできるようになるようです。

■2019 Policy FAQからの抜粋

Data Center Virtualization: VCP5-DCV or VCP6-DCV
Network Virtualization: VCP-NV or VCP6-NV
Cloud Management & Automation: VCP-Cloud, VCP6-CMA or VCM7-CMA
Desktop & Mobility: VCP6-DTM or VCP7-DTM

以前から、VCP更新期限 (2年)についてはやはり学習を含めた準備期間を考えると短い印象がありましたが、今回の更新により多少時間の制限から解放された感があり、多くの認定資格者からは歓迎されるのではないでしょうか。

個人的には今回のポリシー変更により、幅広い製品への更新にもつながることが期待できるかと思います。

[参考情報]

RECERTIFICATION POLICY:VMWARE CERTIFIED PROFESSIONAL
https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/certification/vmw-certification-recertification.pdf

VMware Recertification Rollback 2019 Policy FAQ
https://campaign.vmware.com/imgs/edu/VMware_Recertification_Rollback_FAQ.pdf?mid=24574&eid=CVMW2000040970082

ESXi へSSHログインする際に、パスワード認証が通らない場合は?

CJです。

ESXi環境を管理中、esxcli または ESXi の各種ログ情報を集録するなど、ESXiへSSH接続を行うことケースがあるかと思います。

ところで複数のESXi を管理すると、たまにはパスワード認証が通ったり、通らなかったりした経験ございませんか?

今日はどこの違いによるものかを簡単に紹介したいと思います。

パスワード認証が通る時

例として、TeraTermを使った説明とします。

このように、普通に TeraTerm を開き、接続先のESXi (例. esxi01.cj-lab.com) とポート番号(例. 22) を指定した後、ユーザー名とパスワードを入力すると ESXi へ接続ができます。

パスワード認証が通らない時

“認証に失敗しました。再実行してください。” というメッセージと共に、プレインパスワードを使う項目が選択から外ずれてしまいます。

この場合は、チャレンジレスポンス認証を試してください。

“チャレンジレスポンス認証を使う (キーボードインタラクティブ)” 項目を選択し、

適切なパスワードを入力してください。そうすると、以下の通りに正常に ESXi へSSH接続ができます。

なぜ?

パスワード認証が通る場合と、そうではない場合(チャレンジレスポンス認証が通る場合) の違いは 以下の通りに ESXi の SSH config 設定が異なるためです。

#以下の例は、ESXi 6.7 U1 環境での情報となります。

/etc/ssh/sshd_config
# only use PAM challenge-response (keyboard-interactive)
PasswordAuthentication no #パスワード認証が通る場合
PasswordAuthentication yes #チャレンジレスポンス認証が通る場合
#チャレンジレスポンス認証などについてウェブ上たくさんの情報がありますので、こちらでは割愛させていただきます。
複数のESXiを管理している方で、普段SSHログインはできていて問題はないが、設定が異なること (ログインの仕方が異なる)で気持ち悪いと思う方は、ぜひセキュリティの観点を含めてこの辺の設定変更をご検討いただいたらいかがでしょうか。

 

Nested vSAN on vSAN を構築するには?

CJです。

vSAN環境も進化と伴いバージョンが増えてきている状態です。

vSAN環境が一つしかない状態で、最新の vSANバージョン or アップデート前の vSANバージョンなどで動作テストが必要な場合ございませんか。

今日はそのようなケースにおいて有効な方法である “Nested vSAN ” について紹介したいと思います。

全体イメージ図

まずは、全体のイメージをみるとこんな感じになります。

ネットワークの構成、各VMの細かい表現については割愛させていただきます。

※今回の例では、物理 vSAN環境と離れた基盤上で動いている vCenter から、各物理レイヤーと仮想レイヤーでの疎通ができる前提としてあります。

また、Nested環境自体を構築する方法については、既に別の方が記事を書いてありますので、そちらをご参照ください。

① まずは、物理レイヤーから : ESXi 上でのパラメーター変更

ハードウェア仮想化機能を仮想マシンに提供するため、物理サーバ上の ESXiホストで以下のコマンドを実行します(再起動は不要)。

まずは、以下のコマンドにて現状を確認しましょう。

esxcli system settings advanced list -o /VSAN/FakeSCSIReservations
そうすると、以下のように現状値が確認できます。
Path: /VSAN/FakeSCSIReservations
Type: integer
Int Value: 0
Default Int Value: 0
Min Value: 0
Max Value: 1
String Value:
Default String Value:
Valid Characters:
Description: If set, will fake SCSI reservations without enforcing them. Devel use only. Unsafe and may corrupt data if used incorrectly.
では、早速ハードウェア仮想化機能を仮想マシンに提供できるように、以下のコマンドを入力しましょう。
esxcli system settings advanced set -o /VSAN/FakeSCSIReservations -i 1
echo ‘vhv.allow = “TRUE”‘ >> /etc/vmware/config

設定後、再度確認を行うと、

esxcli system settings advanced list -o /VSAN/FakeSCSIReservations | grep “Int Value”
Int Value: 1
Default Int Value: 0

② 次は、仮想マシン (vESXi) の設定

以下の2箇所を設定します。

③ 次は、NFSを設定

※ vESXi にアタッチする仮想ディスクを、物理 vsanDatastore から切り出して使えばとても楽だと思いますが、本記事を作成している時点ではサポートされていないようです。

そのため、物理レイヤーの vSAN環境上に、仮想マシンとして NFSサーバーを作成します。(NFSサーバー自体の構築方法については割愛させていただきます。)NFSサーバーの作成が終わった後、NFSボリュームを各 vESXi にデータストアとしてみせて、ここから vESXi の vsan Diskを切り出します。

・vSAN-Cluster > ストレージ > 新しいデータストア > NFS > NFS3 > “データストア名”、”フォルダ”、”サーバー” 情報を入力。

・vESXi (VM) > 新規ハードディスク >  vsan disk (Cache, Capacity) を作成。

今回は、Cache:10GB / Capacity: 100GB のディスクを作成しています。

NFSサーバー上のディスクがアタッチされていることがわかります。

NFSサーバー (今回は、CentOSで作成しています。) 内に、vESXi (esxiXX.cj-lab.com) の仮想ディスクが作成されていることが確認できます。

④ Nested-vSAN Cluster 作成

作成した vsan disk が表示されていることがわかります。必要に応じてフラッシュマークをつけましょう。

vSANを有効化して、vsanDatastoreが作成されていることが確認できます。

このように物理環境で制約がある場合、Nestedを活用すると vSANの動作確認には十分有効活用できるかと思いますので、ぜひお試しください。

[参考情報]

Nested ESXi 構築時のレシピまとめ (vSphere 6.5 + vSAN)

Caveat : Running Nested VSAN On A VSAN Cluster

https://www.thinkcharles.net/blog/2018/2/23/failed-to-reserve-drives-in-vsan-nested-environments

ESXi 6系で、起動時間が一番早いバージョンは?

CJです。

約半年前にリリース(2018.4.7)された vSphere 6.7 には、”Quick Boot” という新たな機能が追加されたこと、知っていますか?

今日は “Quick Boot” 機能をみて、ふっと純粋に以下の疑問が沸いたので検証してみた結果を共有したいと思います。

その疑問は、”ESXiの各バージョンごとに、起動時間の違いはあるだろうか?”

その前に、まずは Quick Boot について簡単に紹介させてください。

vSphere 6.7 新機能: Quck Boot

vSphere 6.7 improves efficiency at scale when updating ESXi hosts, significantly reducing maintenance time by eliminating one of two reboots normally required for major version upgrades (Single Reboot). In addition to that, vSphere Quick Boot is a new innovation that restarts the ESXi hypervisor without rebooting the physical host, skipping time-consuming hardware initialization.

上記、VMware vSphere Blog からの引用となりますが、

要は物理ホストの再起動をせず、ESXi を再起動させる機能となります。

ハードウェアの初期化が省略されるため、ESXiのバージョンアップなどのメンテナンス時間が短縮される効果があります。 ちなみに、本機能はサポートされるハードウェアのみに活用できるようです。 ESXi 側で以下のコマンドにて、サポートされているかどうかの確認ができます。

/usr/lib/vmware/loadesx/bin/loadESXCheckCompat.py

特にインフラ管理者には嬉しい機能かと思うので、ぜひお試しください。

検証構成

・比較対象の 各ESXi は vSAN上の Nested 環境で用意してあります。

・各ESXi は同一物理ホスト上で動いてあります。

・各ESXiのスペックは、2Core、4GB ram で同一。

・各 ESXi のバージョンは、以下の通りです。

バージョン Build ESXi名
6.0U3 5572656 esxi09
6.5U1 5969303 esxi08
6.5U2 8294253 esxi07
6.7U1 10302608 esxi06

測定内容

・測定1 : ESXi が停止状態から起動完了までの “起動時間 (秒)”

・測定2 : ESXi が起動状態から再起動完了までの “再起動時間 (秒)”

測定方法

・測定1 : ESXi コンソール画面上で、ESXi ホスト名が表示される画面に繊維されたタイミングまでの時間をストップウェッチにて計測。

・測定2 : ESXi コンソールの再起動直前の画面から、F11により再起動を開始して、ESXi ホスト名が表示される画面に繊維されたタイミングまでの時間をストップウェッチにて計測。

測定結果

測定1 : なんと 6.0U3 のほうが、一番早かったです。

測定2 : 再起動は 6.7U1 のほうが、一番早かったです。

6.0U3 と 6.7U1 間には、微妙な誤差がありそうですが、6.5系と6.7U1間には差ほど大きいな違いはないようですね。数秒の差とはいえ、メンテナンスの際には規模によってこれも短縮したくなるのではないでしょうか。

[参考情報]

ESXi Hardware Requirements
https://docs.vmware.com/en/VMware-vSphere/6.7/com.vmware.esxi.install.doc/GUID-DEB8086A-306B-4239-BF76-E354679202FC.html

Quick Boot Compatibility
https://kb.vmware.com/s/article/52477

Introducing VMware vSphere 6.7!
https://blogs.vmware.com/vsphere/2018/04/introducing-vmware-vsphere-6-7.html

ESXi に残っている vSAN情報を削除するには?

CJです。

vSANクラスター配下で動いている ESXi ホストを、クラスター外に持ち出すケース(クラスター内のホストを別環境に転用したい場合など)があると思います。

今日はその際に使える簡単な Tipを紹介したいと思います。

vSANクラスターから ESXi ホストを外す流れ

1.対象ESXi ホストをメンテナンスモードに切り替え

2.対象ESXi の DiskGroup を削除

3. Drag&Drop にて、対象 ESXi ホストを vSANクラスター外に移動

基本はこれだけでよいはずですが、問題は次の事象です。

 

対象 ESXi 上での操作 (SSH接続)

以下のコマンドにて、vSAN情報が残っていないかを確認。

esxcli vsan storage list
この結果で、vSAN Disk情報が表示された場合は、以下のコマンドにて Disk情報を削除。
esxcli vsan storage remove -u [DISKGROUPのUUID]
もし、vSAN Disk情報など何も表示されてはいないが、vSAN情報が残っていることで別のクラスター環境へ移動ができない場合は、”vdq -q” と “esxcli vsan cluster get” コマンドにて状況を確認。
vdq -q
[
{
“Name” : “naa.600605XXXXXXXXXX2270bcXXXXXXXXXX”,
“VSANUUID” : “”,
“State” : “Eligible for use by VSAN”,
“Reason” : “None”,
“IsSSD” : “1”,
“IsCapacityFlash”: “1”,
“IsPDL” : “0”,
},{
“Name” : “naa.600605XXXXXXXXXX2270bcXXXXXXXXXX”,
“VSANUUID” : “”,
“State” : “Ineligible for use by VSAN”,
“Reason” : “Has partitions”,
“IsSSD” : “0”,
“IsCapacityFlash”: “0”,
“IsPDL” : “0”,
},esxcli vsan cluster getCluster Information
Enabled: true
Current Local Time: 2018-11-05T09:33:53Z
Local Node UUID: 5afe36c2-e2a1-XXXX-XXXX-XXXXXXXXXX20
Local Node Type: NORMAL
Local Node State: MASTER
Local Node Health State: HEALTHY
Sub-Cluster Master UUID: 5afe36c2-e2a1-XXXX-XXXX-XXXXXXXXXX20
Sub-Cluster Backup UUID:
Sub-Cluster UUID: 52dc722d-a2c0-XXXX-XXXX-XXXXXXXXXX85
Sub-Cluster Membership Entry Revision: 5
Sub-Cluster Member Count: 1
Sub-Cluster Member UUIDs: 5afe36c2-e2a1-XXXX-XXXX-XXXXXXXXXX20
Sub-Cluster Membership UUID: 1a9c835b-dd2f-XXXX-XXXX-XXXXXXXXXX20
Unicast Mode Enabled: true
Maintenance Mode State: OFF
Config Generation: a2a65e3c-33ed-XXXX-XXXX-XXXXXXXXXXf2 8 2018-11-05T09:15:51.659

 これで vSAN情報が残っていることがわかりました。
では、早速次のコマンドにて、vSAN情報を削除しましょう。
esxcli vsan cluster leave
これで削除が完了しました。
もう一度、vSANクラスター情報を確認してみると、以下の通りに削除されていることがわかります。
esxcli vsan cluster get
vSAN Clustering is not enabled on this host
上記コマンドは、vSphere 6.5U1 環境での動作確認済みのものとなります。
vSphere バージョンによっては、コマンドが変更されている可能性があります。
その際は、”-?” にて Help 情報を参照してください。

vSphere 6.5以降の環境から仮想マシンを OVAでエクスポートするには?

CJです。

いまさら感がありますが、vSphere 6.5 からは 仮想マシンをエクスポートする際に “OVF”のみがサポートされるようになっているようです。

vSphere6.0 までは、vSphere Client が使えて、仮想マシンをエクスポートする際に OVF or OVA どちらかのファイル形式が選択可能でした。これが、vSphere 6.5 からは vSphere Web Client のみをサポートすることになり、統合プラグイン関係で OVFのみをサポートする形に変わったようです。

とはいえ、やはりファイル1個で使いやすかった OVA は継続的に使いたいですし、移行先のクラウドが OVA のみ対応しているのあれば、なおさらです。

このような状況を踏まえ、vSphere6.5 以降の環境で動いている仮想マシンを OVA にエクスポートしたい方向けにその方法を共有したいと思います。

vSphere 6.5環境で動いている仮想マシンを oVA にするには?

早速ですが、その方法は以下のように、一度 OVFでエクスポートし、それを ovftool を使って OVA に変換することです。

 

 

事前準備

ovftool インストールを踏み台サーバーにインストールが必要です。

ここでは、踏み台サーバーとして Windows を例とします。 Linux または Mac OS X も各自の環境に合わせて適切なパッケージを使えば、使用可能です。

1.OVF Tool Documentation ページへ移動して、最新バージョンをダウンロード

2.ダウンロードしたインストーラーを実行して、インストール完了。

3.環境変数に PATH を登録する (手順は割愛します)と便利。

OVFエクスポート

vSphere Web Client から “仮想マシン > テンプレート > OVF 。。。” メニューからエクスポートを実施。ここでひとつTipとして、OVFエクスポートは HTML5版の vSphere Web Client を使用するのをお勧めします。フラッシュ版の場合、エクスポートのステータスや表示が正常に表示されないケースがあります。

OVAへの変換

OVFファイルの場所例: D:\CJ\powercli\ovftool\ovf\vcsa01_cj-lab.com.[ovf, mf, vmdk]

OVAファイルの変換先例: D:\CJ\powercli\ovftool\ova\vcsa01_cj-lab.com.ova

以下のコマンドを実行する。

>ovftool ./vcsa01_cj-lab.com.ovf ../ova/vcsa01_cj-lab.com.ova

すると、以下のようにコンバートが行われます。

最後に、”Completed successfully” メッセージが表示されれば、完了です。

いかがですか、とても簡単ではありませんか。

個人的にも OVAサポートは継続してほしいところですが、そこは vmwareさんに改善を期待しながら、今現時点ではこのような対策を活用いただければ嬉しいです。

 

[参考情報]

OVF Tool Documentation

https://www.vmware.com/support/developer/ovf/

写真でみる vmworld 2018 US

CJです。

先週たくさんのトピックが取り上げられた vmworld 2018 US ですが、技術的なトピック外のイベント会場雰囲気を簡単ながら写真にて共有したいと思います。

1.出発

2.初日、会場へ

3.登録 (参加証の発行)

4.参加証

5.SOLUTIONS EXCHANGE

この中に各様々なベンダーの展示会があり、VMVILLAGEがあります。

6.VMVILLAGE

多くの参加者が立ち寄る写真スポットです。

7.VMVILLAGEの休憩所

8.PARTNER LOUNGE

9.EDUCATION AND CERTIFICATION LOUNGE

10.VMVILLAGE内のBROADCASTBOOTH

11.VMTN AND VMWARE {code}

12.VMUG LOUNGE

13.VMWARE INNOVATION ZONE

INNOVATION ZONEの写真を撮ろうしたら、ブースの方と目があって、ポーズ取ってと話したら笑顔でハッピーなポーズを取ってくれました。どうも~

14.Drone Racing & Virtual Basketball

このようなちょっとしたゲームも楽しめるのがいくつかあります。

15.MEALS

大事な食事(左)と、1日2回(午前と午後)出される飲み物です。

食事にももちろんコーヒーやアイスティーなどもおいてあります。

16.VMworld FEST

最終日(夜)には、ほとんどのイベントが終わり、フェースが開かれます。

たくさんの参加者と会って話したり、ゲームしたり、踊ったりすることができます。

 

以上、簡単ながらの “写真でみる会場と雰囲気の共有” でした。

vmworld 2018 バルセロナまたは vmworld 2019 (来年はサンフランシスコ開催となります。) への参加をご検討の方に少し約に立てればと思います。

vmworld 2018 US : 参加の事前準備

CJです。

来週から、アメリカのラスベガスで “vmworld 2018 US” が開催されますが、自分も 2年ぶりに参加する予定です。

2年ぶりだと、登録方法も忘れがちなのでまとめながら、普段のTech記事だけでなく、このようなイベント情報についてもシェアしたいと思います。

では、早速イベントの登録方法から見ていきましょう。

1.vmworld イベント登録

vmworld 公式ページにアクセスして、”Register Now” ボタンから登録を開始すればOKです。#vmworldアカウント作成から開始~

Tip1

イベント開始約3ヶ月前から登録が可能になります。早めに登録すると “早期割引”が適用されて、一般人枠であれば 200 USD (例. Alumi枠)ほど節約できます。過去参加4回のイベント中、2回以上本イベントに参加されている方はこの Alumi枠が適用されます。

Tip2

もし、VMware社とパートナー関係である場合、登録時に “VMware Partner ID ” 入力欄が表示されので、Partner IDを入力してください。これにより、パートナー限定のセッションなどに参加することができるようになります。

2.ESTA登録も忘れず

やはり、入国関連の手続きは早く済ませておいた方が良いです。忘れず~

また、申請後の結果の確認も忘れず~事前に確認しておくことをお勧めします。

3.セッション登録

イベントから約1ヵ月半くらい前から登録が開始となります。(今年は、7月中旬からセッション登録が開始されました。) 興味あるセッションを登録していきましょう。

Tip3

たくさんのセッションがあるため、登録前にカタログ上である程度内容が確認できるので、事前に興味あるセッションをチェックしておきましょう。

セッション登録のはじめは、まず “General Session / Partner General Session”からをお勧めします。VMware社のビジョン・戦略・方針をはじめ、署名 Guest Speaker のお話を生で聞くことができます。

人気セッション (vSphere、vSAN、NSXなど)の場合は、すぐ満員になりますので早めに登録するのがベターですが、開始して間もないところで登録できなかった場合でも諦めず、一旦 “Wait List” でも登録しておきましょう。VMware社もどのセッションにどれくらいの人が集まるかわからないはずです。(ある程度予測はできるものの) 一旦登録しておけば、後の会場の変更などを行いつつ参加可能の人数枠を増やすケースがあるようです。(Wait Listからいつの間にか Scheduled状態に変わります。)

4.現地のイベント情報もチェック・登録

vmworldに参加する各会社が主催するイベントはもちろん、vmwareが主催するパートナー関連イベント、vExpert向けのイベント、VMware User Group(VMUG)向けのイベントなど、たくさんのイベントが開催されます。世界各地から集まるユーザー達と交流しながら、色々なお話ができる良い機会ですので、ぜひ活用してください。(結構、時間がバッティングするこも多いので、各自のスケジュールをを要調整) また、このような情報は検索エンジンやSNSなどから入手できるため、興味あるイベントには事前に登録しておくことをお勧めします。

#RUN DMC、The Roots、Snoop Dogg などパフォーマーがすごいですね。。

5.vmworld アプリのインストール

Android, iPhoneなどの事前に vmworld用アプリを入れておきましょう。

アップストアで公開されるのは、イベント開始前の約2週間前となります。

自分が登録したセッションのスケジュールはもちろん、会場、無料wifi情報、各イベント情報も確認できるなどとても便利です。セッション聞きながらメモを取ってそれをメールに飛ばせるようにもなっているため、イベントのマストアイテムです。

 

以上、簡単ながら事前準備編をシェアさせていただきました。

次回は、現地の情報・雰囲気もシェアできればと思います。

CentOS7に PowerCLI をインストールするには?

CJです。

vSphere 環境をより柔軟に管理するには、PowerCLIが必要かと思います。

この PowerCLI、実は Linux 上でも使えること知っていますか?

使えるんです。PowerCLI Coreという形で Linuxでも使用可能な状態で配布されましたが、以下のように PowerCLI 10.0 からは Coreという形はなくなり、PowerCLIに統合された形での配布となっています。

 PowerCLI Core has been officially released as part of PowerCLI 10.0. This Fling is no longer under development and future multi-platform support will be a part of PowerCLI 10.0.

今回は、CentOS7上で PowerCLI をインストールする方法について共有したいと思います。

STEP1. まず、PowerShell をインストール (on CentOS7)

以下のように、マイクロソフトのリポジトリを登録。

# vi /etc/yum.repos.d/microsoft.repo

[packages-microsoft-com-prod]
name=packages-microsoft-com-prod
baseurl=https://packages.microsoft.com/rhel/7/prod/
enabled=1
gpgcheck=1
gpgkey=https://packages.microsoft.com/keys/microsoft.asc

1-1. 安定版をインスールする方法。(お勧め)

この後は、普通に yum で PowerShell をインストール。

# yum install powershell

1-2. 最新版をインスールする方法。

以下のサイトより、自分の環境に合うバージョンをダウンロードしてインストール。(ここの手順は省略)

https://github.com/PowerShell/PowerShell/releases

インストールが完了したら、powershell 起動。

# pwsh
PowerShell v6.1.0-preview.2
Copyright (c) Microsoft Corporation. All rights reserved.https://aka.ms/pscore6-docs
Type ‘help’ to get help.
PS /root>

STEP2. 続いて、PowerCLI をインストール (on CentOS7)

PS /root> Install-Module -Name VMware.PowerCLI
PS /root> Get-Module -ListAvailable
PS /root> Set-PowerCLIConfiguration -InvalidCertificateAction Ignore

STEP3. 最後に、vCenterへのアクセスを試す (on CentOS7)

PS /root> Connect-VIServer -server [vCenter名 or IPアドレス]

Linux のログサーバーから vCenterのイベントログなどを収集したいケースなどあると思いますが、ぜひ必要に応じて Linux 上でも PowerCLIが動くことを覚えてお試しいただければと思います。

[参考情報]

https://github.com/PowerShell/PowerShell/releases

Installing VMware PowerCLI 10.0.0 on Linux

https://virtualizationreview.com/articles/2017/06/01/how-to-install-and-use-powershell-and-powercli-on-linux.aspx

On-Disk フォーマット更新時のサービス影響は?

CJです。

vSphere 5.5の End of General Support (2018/09/19) が近づいていることもあり、このタイミングでの移行やそれに伴うバージョンアップを検討されるケースは多くあるのではないでしょうか。 特にバージョンアップの際に実際仮想マシンへの影響度合いも気になるかと思います。

今回は、vSAN基盤のバージョンアップ (ESXi 6.0U3 → 6.5U1) を行う中で、On-Disk フォーマットというプロセスが発生します。Diskに関するところでサービス (仮想マシンの通信)影響が発生するか否かについて共有したいと思います。

ちなみに、On-Disk フォーマットについてはこちらを参照してください。

テストイメージ図

上記のように、同一の vSAN環境 (vsanDatastore) 上で稼動している仮想マシン(CJ01、CJ02)間の疎通 (ping) を行いつつ、On-Diskフォーマットを更新して結果を確認したいと思います。

vSAN設定画面 (更新前)

vCenter > vSAN Cluster > 設定 > vSAN > 全般 > オンディスクフォーマットのバージョン

こちらの画面で “アップグレードの事前チェック” ボタンをクリックする、vSAN内部で更新ができるかどうかをチェックしてくれます。

アップグレード

事前チェックが正常に完了した後、”アップグレード” ボタンをクリック。すると、

アップグレード開始確認画面が表示されるので、”はい” で次へ。

※冗長性の低下を許可を選択すると、更新がなんらかの理由で失敗した場合にデーター損失につながる可能性がありますので、各自の環境に合わせて注意してお使いいただければと思います。

進行内容は以下の通りとなります。

0 ~     5%:クラスタのチェック。
5 ~   10%:ディスク グループのアップグレード。
10 ~ 15%:オブジェクトの再編成。
15 ~ 95%:ディスク グループの削除および再フォーマット。
95~100%:最終的なオブジェクト バージョンのアップグレード。

vSAN設定画面 (更新後)

ご覧のように、ディスクフォーマットのバージョンが更新 (3.0 → 5.0) されていることがわかります。

サービス(通信)影響は?

パケットロスゼロのサービス(通信)影響はありませんでした。

vSAN基盤を更新する上で、忘れがちなところでもある On-Diskフォーマットですが既存フォーマットの違いを理解した上で必要に応じて忘れず更新いただければと思います。

TIP (RVC : 更新ステータス確認方法)

vsan.upgrade_status /localhost/[DATACENTER]/computers/[CLUSTER]

RVCにログイン上、上記コマンドにて更新ステータスが確認できます。

vsan.upgrade_status -r [秒] /localhost/[DATACENTER]/computers/[CLUSTER]

また、秒指定 (min 60秒) をすると、ユーザーが “Ctrl + c” で抜けない限り画面上更新情報を指定秒間出力してくれます。

運用上、ぜひRVCモードもご活用ください。

 

[参考情報]

vSAN ディスク フォーマットについて

https://docs.vmware.com/jp/VMware-vSphere/6.5/com.vmware.vsphere.virtualsan.doc/GUID-08728A9E-88E0-4CEB-9764-E828719DA927.html

Disk format change going from 6.x to vSAN 6.6?

Disk format change going from 6.x to vSAN 6.6?