20201いったいどれくらいの人がこのナレッジの恩恵を受けるのかは不明ですが、一応共有しておきます。VMware関連のナレッジを発信している筆者ですが、ちょっと前までURLがごちゃごちゃするのが悩みでした。具体的には以下のような感じになってしまいます。【イントロダクション】URL:https://communities.vmware.com/people/nkaneda/blog/2019/09/24/vxrail-%E6%97%A2%E5%AD%98%E7%92%B0%E5%A2%83%E3%81%8B%E3%82%89vsan-%E7%92%B0%E5%A2%83%E3%81%B8%E3%81%AEmigration-%E3%81%9D%E3%81%AE-%E3%82%A4%E3%83%B3%E3%83%88%E3%83%AD%E3%83%80%E3%82%AF%E3%82%B7%E3%83%A7%E3%83%B3上記を見ればわかるように日本語のタイトルでブログを執筆するとタイトル=URLになる関係上、マルチバイト文字がURLエンコードされて、かなりごちゃごちゃします。筆者はブログを仕事でも活用(ナレッジの紹介など)しているため、URLがごちゃごちゃするのが何となく嫌でした。URLだけみてどの記事なのかの判別も不可能ですし。ちなみに上記の仕組みにはもう一つ難点があって、上の例ですとブログタイトルの「その1」の1の部分がどうやら環境依存文字として正しく認識されないらしく、2も3も同じタイトルして扱われてしまうようです。そのため、2や3を執筆すると同じURLになってしまう、という不具合があります。解決方法この問題の解決方法はいたってシンプルです。Draftで保存します。すると、この段階でのブログタイトルでブログのURLが作成されます。そのあと、ブログタイトルを変えたとしてもURLは維持される仕様のため、URLがエンコードによってごちゃごちゃするのを防げます。下記の図は、本ブログを作成したときの様子ですが、いったんASCII文字のみでブログタイトルを記述しているのがわかると思います。この時のタイトルが、いまあなたがアクセスしているURLに反映されます。大したことのないナレッジですが、これによってURLをコピペするときもすっきりしますし、うっかり間違った記事を案内してしまうミスも減らせます。20190最近vSphere関連の以下の記事をフォローするようになりました。Insider定期的に各製品に関する流行り(?)のKBが紹介されているのでサポートの人間としてはぜひとも押さえておきたいところです。先日のUpdateにて、以下のKBを見つけました。Client経由でのデータストアへのファイルのUploadやOVA/OVFのデプロイが失敗する、という内容のKBで、サポート観点でいえば、問い合わせが来るたびに「あー、あれね。」となるような事象です。今回このKBに注目した理由として、私自身がこのKBをしらなかったためです。この事象自体はよく知っていて、何度も解決策を案内していたのですが、一度もこのKBにたどり着くことはできませんでした。調べてみるとこの事象でエラーになった際のエラー画面にバッチリこのKBの番号が書かれてるんですね。エラー画面を送ってくれない人も多いので全く気付いてませんでした。フォローしてよかった、と思った次第です。Date(External)ではないので注意が必要です。Dateはあくまでも、KB自体が最初に作成されたタイミングのようで、外部向けに公開された日付とは限りません。6.7U3の公開(2019/8/20)よりも前に公開されてはいませんでした。Dateを気にする場面は少ないと思いますが、もし確認される際は↑の事実をご留意ください。20190Unmapの必要性vSANのサポートをしていると時々「容量が足りない!容量を空ける方法を教えてほしい」といった問い合わせを受けることがあります。Storageのサポートをしていた時からたびたびこういう問い合わせを受けますが、ベンダーだけが知る秘密の方法、みたいなものはないので基本的にはお客様のデータを削除していただくか、Diskを追加して容量を拡張していただく、という形になります。※お客様の使い方を効率化することで空き容量を捻出できる場合もあると思いますが、基本的にはサポートでなく有償のコンサルタントサービスになるのが一般的と思います。サルに金を出すくらいならその金でDiskを買うか、自分で勉強したほうがいい、というのは私の個人的な意見です。多くのお客様は上記のようなことはご承知なので、データの削除をしてくれます。「GuestOSでデータを削除したのにvSANの空き容量が増えない」というお問い合わせを受けることがあります。Provisioningとなりますので、vSAN上の仮想マシンが仮想ディスクを消費するたびに領域が少しずつ割り当てられていく、という仕組みになっています。一度割り当てられた領域は割り当て済みとなるため、たとえその領域が使用されていなかったとしてもあとから回収することはできません。Thickのようにすることはできますが、デフォルトはThinなので特に指定しない限り上記のような動作になります。具体的には以下のような感じになります。最初に100GBの仮想ディスクを持つ仮想マシンをvSANデータストア上にThinで作成し、その上にOSをInstallしたとします。Install直後は10GBほどしか使われてないとすると、対象の仮想ディスクのvSANデータストア上での容量も10GBほどになります。その後、GuestOSにて50GBの書き込みを実施したとします。するとvSANデータストアで対象の仮想ディスクに追加で50GB分の容量が割り当てられるので、合計で60GBとなります。その後、あとから書き込んだ50GBのデータを、GuestOS上で削除した場合、GuestOS上でのDisk使用率は低下しますが、vSANデータストアにおいてはすでに60GB分が割り当て済みなので、対象の仮想ディスクのvSANデータストア上のサイズは60GBのままです。(GuestOS上では10GB分のサイズしか使用してない)この場合、対象の仮想ディスクに割り当て済みだが、実際には使用されていない容量が50GBあることになります。この50GBはvSANデータストア上のほかの仮想ディスクですることもできず、かといって対象の仮想ディスクを使用するGuestOSからも使用されてないので完全に無駄な領域となってしまいます。vSANデータストア上に作成した仮想マシンにて、上記のような作業を繰り返してしまった場合、実際に使っている量よりも明らかにvSANの使用容量が多いぞ?ということになってしまうわけです。この問題を解決するためには、GuestOSで使用されなくなった領域をvSANデータストアに返却する仕組みが必要です。その機能のことをUnmapといいます。6.7U1からサポートされました。(デフォルトでは無効)この機能を利用することで、上記のような容量管理上無駄となってしまう領域を再利用することが可能になります。formatも7以上である必要があります。Docから確認できます。VMware細かい使用方法や前提条件(仮想ハードウェアのVersionなど)は上記の公式ドキュメントに譲りますが、大体の流れとしては以下のようになります。前提条件を満たしていることを確認RVCにて機能を有効化する。各GuestOSごとの設定GuestOS側での対応についてUnmapのオペレーションはvSAN側から開始するものではなく、GuestOS側から開始するものです。いうとも、vSANデータストア側からは、GuestOS内でどの領域を使用しているのかが不明なため、GuestOSがストレージ側(vSAN)にどの領域を解放してよいのかを教えてあげる必要があるためです。Widowsサーバの場合、2012以降であればこのUnmapを開始する作業(Trim)がデフォルトで有効になっているため、特に問題はないと思いますが、Linux環境ではちょっとOSや環境に応じて個別の対応が必要になるかもしれません。※あくまでも私の認識ではありますが、TrimとUnmapは同じ意味であり、OSの文脈ではTrimが使われ、Storageの文脈ではUnmapが使われることが多い印象です。厳密には異なるかもしれませんが、少なくともこの記事ではTrim=Unmapとして記載してます。※※WindowsサーバにおけるTrim設定の確認や動作検証などは以下のブログが参考になると思います。私の環境ではLVMを利用したCentOS7でした。その場合は以下の対応が必要となりました。lvm.confの編集LVMの場合は実際にDiskを管理しているのLVMサービスになりますので、LVMにてTrim/Unmapを有効化する必要があります。1にしてあげる必要があります。fstabの編集ファイルシステムでもTrim/Unmapを有効化してあげる必要があります。編集して対象のファイルシステムにdiscardオプションをつけてあげる必要があります。XFSファイルシステムでフォーマットして、/homeとしてマウントしていましたので、fstabには以下のように設定されてました。defaults,discardとして、discardオプションを足しました。設定が終わったらTrimを実行してあげる必要があります。Docによるとfstrimコマンドで実施することが推奨とありました。/homeのファイルシステムに対して実行したい場合は、以下のような形式で実行します。※不要なファイルはあらかじめGuestOSレベルで削除しておいてください。※※設定直後はコマンドが成功しないことがありました。その場合はいったんRebootしてあげてください。オプションはつけなくてもいいのですが、つけないと何も出力が返ってこないので、私はつけるようにしてます。(なんとなくの安心感があるので。)Unmapの結果や進捗を確認するfstrimコマンドを実行した場合、出力は比較的すぐに返ってきます。そんな短時間にUnmap処理自体が完了したわけではありません。私の理解ではOSはUnmapの処理をStorageに指示するのみで実際の処理はStorage側で実施されているはずです。vSANの場合もOS側から進捗や結果を確認することはできず、vSANの統計情報や、vSphereの消費容量から確認することになります。IO情報が個別の項目として存在するのでそこから確認可能です。IOは対象の仮想マシンが稼働するホスト上で記録されます。BのvSAN統計情報を確認する必要があります。パフォーマンスから確認できます。以下がUnmap前の統計情報です。UnmapのIOPSがずっとゼロであることがわかります。以下がUnmap後の情報です。スループットが記録されています。IOがなくなったら完了、と言えそうです。Client(HTML5)から、vSANの空き容量が増えていることを確認したり、対象の仮想マシンがデータストア上で消費する容量が減っていることで確認できます。今回はキャプチャをとり忘れてしまったのですが、実際にやってみる際は事前と事後の容量を比較してみるといいと思います。Unmapされない?きちんと設定したはずなのに、想定通りにUnmapが走ってくれない場合もあると思います。対象の仮想マシンでSnapshotがある場合は、Unmapしたい領域をSnapshotが使っていて解放されないことがあるようです。Snapshotがない場合でも、Replicationなどのソリューションが介在している場合、うまく動作しないことが考えられます。EMCのRP4VMでReplicationを行っている仮想マシンに関してはUnmapが動作しませんでした。詳細なロジックや追加検証にて確認すべき余地はあるため、確定情報ではないですが、Unmapがうまくいかない場合は、SnapshotやReplicationなどの機能をOffにしたり削除したりといった切り分けが有効化と思います。いかがでしたでしょうか。vSANは70%程度の容量使用率が推奨されている関係もあって、いきなり容量が足りなくなる、ということはほとんどないとは思いますが、空き容量が少なくなってくると、vSANの動作に影響が出たり、パフォーマンスが出なかったり、障害時に可用性が維持できないなどの問題が生じます。現在空き容量でお困りではないユーザであっても、使用していない領域を再利用できるに越したことはないと思います。6.7U1以前のVersionをお使いの場合は、ぜひともUpgradeをご検討ください。このブログの内容が運用や管理の助けになれば幸いです。