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

 

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

vSAN オンディスク フォーマットとは?

CJです。

vSANにはファイルシステムフォーマットがあり、それをオンディスクフォーマットと呼んでいるようです。 ところが、VMware 製品関連でよく聞き慣れているファイルシステム名としては、VMFS、VSANFSなどもあり、混乱しやすいのではないかと思います。そのため、今回はvSANにおけるファイルシステム名の違いを簡単に整理して共有したいと思います。

 

早速、簡単に比較表でまとめてみました。

上記表にあるバージョン情報をvSAN環境で確認するには、

vSphere Web Client上の “クラスタ > 管理 > 設定 > Virtual SAN 全般” から確認できます。(例. vSAN 6.2環境 : 3.0 の最新となっています。)

以下の通りに、RVC (Ruby vSphere Console) からもオンディスクフォーマットのバージョンが確認できます。

vsan.disks_stats localhost/DC名/computers/CLUSTER名

vsan.disks_info

ちなみに、RVCは以下のパスで起動できます。(例. Windows Server 12R2 環境)

C:\Program Files\VMware\vCenter Server\rvc\rvc.bat

以上、簡単ではありますが、オンディスクフォーマットのバージョンの違いおよびバージョンの確認方法の共有でした。 vSANのファイルシステム名で混乱している方、vSANバージョンアップを検討中でオンディスクフォーマットのバージョンを確認したい方などへ少しでも役に立てればと思います。

 

[参考情報]

VMFS-L
https://books.google.co.jp/books?id=GHI3DAAAQBAJ&pg=SA3-PA109&lpg=SA3-PA109&dq=VMFS-L&source=bl&ots=bCNuuvV9sn&sig=onPiESvJUUJs54RCzlNuZBjzioc&hl=ja&sa=X&ved=0ahUKEwiN2IXS6erVAhVBTLwKHe74DrIQ6AEISTAE#v=onepage&q=VMFS-L&f=false

VSANFS
https://www.packtpub.com/mapt/book/virtualization_and_cloud/9781784399252/9/ch09lvl1sec47/the-new-on-disk-format

vSAN オンディスク フォーマットのバージョンと互換性について (2147615)
https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2147615

vSAN 6.6.1 がリリースされました。

CJです。

先日、ESXi 6.5 Update 1 のリリースに合わせて、vSAN6.6.1 がリリースされました。

新機能としては、以下の3点が挙げられます。

  1. VMware Update Manager (VUM) に vSANが統合されました。 #VUMを通して通常の vSphere 環境と同じく vSANのバージョンアップなどを行うことができるようになりました。
  2. パフォーマンス診断ができるようになりました。
  3. vSANディスク上のLEDロケーターサポート向上 (HPE Gen-9 Controller : pass-through mode)

 

せっかくなので、以下 vSAN6.2 ~ 6.6.1 までの追加された新機能の一覧表を共有します。

vSAN の成長と伴う新機能の追加が今後も楽しみです。

 

[参考情報]

http://pubs.vmware.com/Release_Notes/jp/vsan/62/vmware-virtual-san-62-release-notes.html

http://pubs.vmware.com/Release_Notes/jp/vsan/65/vmware-virtual-san-65-release-notes.html

http://pubs.vmware.com/Release_Notes/jp/vsan/66/vmware-virtual-san-66-release-notes.html

https://docs.vmware.com/en/VMware-vSphere/6.5/rn/vmware-vsan-661-release-notes.html

vSAN ディスク故障時、適切なディスク交換手順とは?

CJです。

前回は、vSAN環境でディスク故障時に仮想マシンが受ける影響について共有しました。

今回は、その延長でディスク交換の適切なオペレーション方法を共有したいと思います。

 

まず、前提となる構成は以下の通りです。

前提構成 & 故障シナリオ

vSAN:6.2 All-flash

ホスト : 6台

DiskGroup: 1Group/ホスト

※安定の2重故障まで対応可能な RAID-6相当の構成です。(FTT=2, RAID-5/6 Erasure Coding)

故障シナリオ:キャパシティディスク1本が故障

 

適切なオペレーションの流れ

以下、ディスク故障から復旧まで、全体的な流れとなります。

詳細

ディスク故障発生

ディスク故障が発生した場合、以下のようにディスクが Absent 状態になります。

ESXi : メンテナンスモード

実はホストをメンテナンスモードにせずに、この後のディスクグループの削除なども行えるケースもありますが、ディスク故障時においてはまずホストをメンテナンスモードに変更することを強くお勧めします。

Virtual SAN データの移行オプションとしては、RAID-6相当の構成であること、別の空きディスクグループ (ストレージポリシーを守れる予備領域)が存在しないため、ここでは “データの移行なし” を選択しています。

故障ディスクが入っているホストがメンテナンスモードに変更されたら、次へ

GUI:対象 DiskGroup 削除

vSAN All-flash構成においては、キャッシュ または キャパシティどちらのディスクでも1本故障した場合は、そのディスクグループが使えなくなります。(vSAN 容量が減ります。)

この場合は、DiskGroupの再作成で復旧することが可能です。

参考:こちらの削除をCUIで行う場合は、以下のコマンドを活用してください。

esxcli vsan storage remove -u [DISKGROUPのUUID] –evacuation-mode=noAction

物理:DISK交換

ホストがメンテナンスモードに移っており、ディスクグループが削除されていれば vSAN上でのディスク交換準備は完了です。この後に、物理ディスクを交換してください。

環境に合わせて、RAID-0の設定が必要な場合は忘れずに設定してください。

GUI:対象 DiskGroup 作成

ディスク交換が完了したら、ディスクグループを再作成します。

その前に、All-flash構成のため、忘れず交換したディスクにフラッシュマークをつけましょう。

続いて、DiskGroup を再作成してください。

これでDISK故障から復旧となります。

確認

vSANはディスクグループが復旧したら、バックグラウンドで自動的に最同期が走ります。

Tip>

vSphere Web Client 上で、最同期が進んでいることが確認できますが、こちらの表示がうまく表示されない場合は、下記のRVC (黒い画面)画面での確認を試してみてください。

 

まとめ

一通り流れをみてみましたが、いかがでしょうか。

ディスクグループの削除などはオンラインでできるケースもあるため、実際ディスク故障時には間違ったオペレーションにより、vSANの想定外動作につながるケースもあると思います。

そのため、本記事を参考に少しでも適切な運用手順において、本記事が役に立てればと思います。

Tip>

より、安定した vSAN環境の運用を行いたい場合は、”2DISKGROUP/ホスト” をお勧めします。

 

[参考情報]

https://docs.vmware.com/en/VMware-vSphere/6.0/com.vmware.vsphere.virtualsan.doc/GUID-9A2DCE0B-CFA1-41C1-97CE-DA56A55426EA.html

vSAN ディスク故障時の仮想マシンの操作はどうなる?

CJです。

vSAN 環境において仮想マシンのデーターは ErasureCoding 機能により、RAID6相当の2重障害まで保護が可能です。 ところで、実際 DISK障害などが発生した際に、RAID6相当範囲内であれば仮想マシンはまったく何の影響もなく、使えるんでしょうか?

結論から伝えると、仮想マシンのデーターは保護されている状態ですが、一部の操作については影響を受けることとなります。

以下、実際仮想マシンが障害時 (DISK障害想定) に受ける影響の一覧表です。

#環境情報:ホスト6台のRAID6相当の構成、1DISKGROUP/ホスト。

こちらの表を少し補足すると、

RAID6相当の環境 (2重障害まで許容)で、稼動中の仮想マシンが1台、停止状態の仮想マシンが1台があり、この環境でキャパシティ用のDISK 1本が故障した際の動作を確認したものとなります。

スナップショット

スナップショットは作成も、復元も使えなくなります。取得してあったスナップショット削除することは可能です。

移行

同一 vsanDatastore でのホスト移行 (vMotion) は可能ですが、クラスタを跨いだ移行は基本できなくなります。

クローン作成

クローン作成もスナップショットも同じく使えなくなります。

設定の編集

当然といえば、当然ですが、仮想ディスクのサイズ変更はできなくなります。

#仮想マシンのネットワークアダプタ変更などは可能です。

なぜ、このように操作ができなくなるの?

これは vSANの構成による仕様のようです。

vSANは DISKが故障した際にリペアを試みる動きを行いますが、上記構成では代替となる空き領域がなくてリペアが完了できない状態です。 また、上記の操作を行うには vSAN内部で Component を作成する形となりますが、物理環境上 RAID6相当を満たせない状態のためです。

DISK障害時にも、上記の操作ができるようにするには?

お勧めはやはり、ホストごとに2つのDISKGROUPを持つことです。

そうすると DISK故障時に vSANが自動的にリペアを試みて空き領域(同一ホスト内の別DISKGROUP or 別ホストのDISKGROUP)があれば、障害状況が復旧となり、スナップショット・クローン作成などの操作もできるようになります。

※他の障害 or 構成によっては別の方法での対応が必要な場合もあります。

 

以上、vSANの動きを知り、日常の運用において少しでも役に立てればと思います。

 

[参考情報]

https://docs.vmware.com/en/VMware-vSphere/6.0/com.vmware.vsphere.virtualsan.doc/GUID-9A2DCE0B-CFA1-41C1-97CE-DA56A55426EA.html