[VMware] vROps 6.6リリース

他のプロダクトより短い間隔で新しいバージョンがリリースされているvROpsの新しい6.6バージョンが6月上旬リリースされました。このvROpsはVMware社のSDDC戦略のコアプロダクトの一つとして、バージョンを重ねるに連れて他のプロダクトのモニタリング機能が追加されつつあります。

 

今年3月にリリースされた6.5まではある意味バグ修正と性能安定が中心でしたが、本6.6は見た目から大きく変更されています。

まず、UIが大きく変わりました。遂にvROpsもHTML5対応になりました!祝!

よって画面遷移はもちろん全体的に操作が非常に軽いです。

※ご覧ください!このシンプルでキレイなUIデザイン!

 

HTML5化に伴いメニューも変更されました。プロダクト中心だったダッシュボードも操作、容量、パフォーマンスやトラブルシューティングにカテゴライズされ、より簡単にインフラのヘルス状態の確認できるようになりました。

※パフォーマンスのトラブルシューティングダッシュボードではプロダクトの種類と関係なく、仮想マシンを始めvSAN、クラスタ、データストアなどカテゴリでその状態が確認できます。

 

もう一つ大きい変更はvSANのモニタリング機能が統合されたことです。6.5まではvSANの環境をモニタリングsるためにはMPSD(Management Pack for Storage Devices)を別途インストールする必要がありました。6.6ではこのモニタリング機能が統合されMPSDをインストールする必要がなくなっています。(もちろん他のストレージをモニタリングするためにはMPSDをインストールする必要があります)


※ No more MPSD for vSAN! 🙂

 

以外にも仮想インフラ上の負荷状況を分析、vRAでデプロイする仮想マシンを最適なホストに位置させる自動ロードバランス機能やvSphereのハードニングコンプライアンス状態が確認できるダッシュボードも追加されました。

※パフォーマンスだけではなくコンプライアンス準拠状態も確認できます。

 

詳しい内容はリリースノートドキュメントをご確認ください。

[VMware] vSANネットワークデザインガイド

vSAN 6.6バージョンに合わせたネットワークデザインガイドがリリースされました。

VMware vSAN Network Design

 

以前バージョンではPDFのみ提供されましたが、今回は非常に分かりやすいオンラインページとして構成されています。(もちろんPDFファイルとしもダウンロードできます)

ネットワークアダプターのチーミングのような基本的な構成から拡張クラスターやiSCSIターゲットの構成などのベストプライクティスと手順が含まれていますので確認してみてください。

 

 

[VMware] これからはVSANではなくvSAN

ブログやメール、そしてドキュメント作成時、皆さんは正確に製品名を使っていますか?

個人的には常に正しい製品名を使用しようと心かけています。例えばVMwareをVMWareに、vSphereをVsphereなどに表記しません。格好悪いじゃないですか。:)
もちろんVSANもきちんと大文字で使ってきましたが、数日前以下のようなツイートがありました。要はVSANは今後、vSANvのみ小文字)に変更されたということです。

ツイートに書かれているとおり、vSphereに統合されている意味で大文字’V’ではなく小文字’v’に変更するようになったようです。
すでにVMware社公式アカウントの一部はvSANとして表記しています。
ブログやドキュメント作成の際にはご注意ください。

その他、製品の正しい表記についてのドキュメントもありましたね。

[VMware] VSANのベータテストに参加しませんか?

もはやVMwareソリューションの主力の一つになっているVirtual SAN(VSAN) 次期バージョンのベータテストが公開されました。

 
誰よりも次期VSANを触ってみたい方、開発チームへ意見を反映したい方は是非ご参加を!!!(ただし、応募者、全員がテストに参加できるわけでは無さそうです。(;゚д゚)ァ….)

vsan-beta-test

 

参加の申し込みはこちらから。

[VMware] VSAN 6.x Ramdisk is full エラー

VSAN 6.1を構成後次のようなエラーが発生することがあります。

The ramdisk ‘vsantraces’ is full. As a result the file /vsantraces/vsanObserver*********.gz could not be written.

 

■ 原因

既知のイシューのようです。ログがローテートされず300MB単位で生成されてしまうようです。
現在恒久的な改善方法はなく、修正パッチが公開されるとのことです。

The ram disk vsantraces is full

自分が知ってる環境ですとVSAN 6.1で、ESXiを内蔵SDカードにインストールした場合でした。

 

■ 改善方法

2016年7月現在、根本的な改善方法はありません。ワークアラウンドとして /var/log/vsantraces の古い.gzファイルを削除することでエラーの発生を抑制できるとのことです。

 

本事象ではありませんが、同じ原因でVSAN 6.1から6.2へのアップグレードが失敗してしまうケースがあるようで、VSAN 6.2のリリースノートにも同じワークアラウンドが記載されています。

VSAN 6.2 リリースノート

 

 

 

[VMware] Enterprise Plus以外のエディション+VSAN組合せ時の注意点

ご存知かもしれませんが、VSANライセンスには分散スイッチが含まれています。ということはvSphere Enterprise Plusエディションを購入しなくても分散スイッチ(vDS)が使えるということです。

vsan-licensing

VMware Virtual SAN 6.2 Licensing Guide

 

それじゃ、vSphere StandardエディションでもVSANのライセンスを替えば、vDSが使えるじゃん?
そうでーす。vSphere StandardエディションでもvDSが使えます。

 

が!!!
ライセンス的には問題がありませんが、実際に環境の構築する際には注意すべきことがあります。
注意すべきことはライセンスの適用順序です。

 

ESXiを含む多くのVMware製品はインストールの際、ライセンスの入力を求められません。
自動的に(?)評価版のライセンスが適用され60日間最上位エディションの機能を使えます。なので一般的に(と言ってよいのか分かりませんが)、この”評価版のライセンスの状態で環境を構築し、最後のライセンスを適用”という方も多いのではないでしょうか。
このやり方だと痛い目に合うのが、【vSphere Enterprise Plus以外のエディション】と【VSANライセンス】によるvDS+VSAN構成です。
よくありがちな構築順は ① ESXiインストール → ② vCenter Server構築 → ③ クラスタ作成、ESXiの登録 → ④ vDS作成/構成 → ⑤ VSAN有効化/ディスクグループ作成 ではないでしょうか?
ライセンスの適用は、自分なら⑤のあとでしょうかね。汗
これじゃ、ダメです。

 

【vSphere Enterprise Plus以外のエディション】の場合、⑤のあとでライセンスを適用しようとすると、以下のエラーで適用できなくなります。

License downgrade. Cannot assign the license key, it does not support all the featues that are in use.

The following featues are in use:
vSphere Distributed Switch

Turn off the features that are in use to proceed with the assignment.

 

要は、”vDSはYOUのライセンスだと使えないよー。ライセンスを適用したければvDSを削除してねー。”ということです。
VSANライセンス別に買っていて、適用済みでも改善されません。方法はvDSを削除するしかありません。(もしくは一旦vDSを全部vSSに変える)

 

【vSphere Enterprise Plus以外のエディション】と【VSANライセンス】によるvDS+VSAN構成の正しい順番は次のとおりです。

① ESXiインストール
② vCenter Server構築
③ クラスタ作成、ESXiの登録
④ ライセンス適用(ESXi、vCenter Server、VSAN)
⑤ VSAN有効化(VSANを有効にしないと、vDSを作成しても追加するホストが表示されません)
⑥ vDS作成/構成
⑦ ディスクグループ作成

 

ご注意ください。

 

PS> オフィシャルな情報があれば良いですね。【vSphere Enterprise Plus以外のエディション】と【VSANライセンス】によるvDS+VSAN構成をする顧客が殆どいないんですかね。。。

[VMware] VSAN上に大きい仮想マシンを作成する場合

ご存知のとおり、VSAN 5.5ではサポートするvmdkの最大サイズが2TBでした。これが6.0になってからは最大62TBまで大きくなりました。そのためVSANでTB級仮想マシンも作成、運用が可能になりました。

しかし、TB級仮想マシンを作成する際には、VSANならではの考慮すべきことがあります。

 

VSANの場合、vmdkファイルなどのオブジェクトをストレージポリシーによるコンポーネント単位でHDDに書き込みます。このコンポーネントは最大サイズがあり、そのサイズは255GBです。
オブジェクトサイズが255GBを超える場合、VSANでは自動的に複数のコンポーネントに分かれ複数のHDDに書き込まれます。例えば1TBのvmdkファイルの場合、最終的にHDDに書き込まれるコンポーネントの数は4つ以上となります。FTT=1の場合は計8つのコンポーネントができます。
もう一度言いますが、分割されるのはコンポーネントです。オブジェクトではありません。分割されたコンポーネント情報はメタデータで管理されます。なのでvsanDatastoreのデータストアブラウザでは1つのvmdkファイルしかありません。

それじゃ、分割されたコンポーネントは同じESXiホストに格納されるのでしょうか?それとも別のESXiホストに格納されるでしょうか?
これは各ESXiホストのディスクグループの使用率や負荷状況によって同じESXiホストに格納されることも別のESXiホストに格納されることあるようです。

 

LargeThan255GB-01

約400GBのvmdkファイルを持っている仮想マシンです。400GBのvmdkファイル以外にOS領域として数十GBのvmdkファイルも持っています。

 

LargeThan255GB-02

まず、仮想マシンのOS領域のvmdkファイルをみてみましょう。FTT=1のストレージポリシーなのでコンポーネントは2つ作成されそれぞれ異なるESXiに書き込まれていることが分かります。

 

LargeThan255GB-03

LargeThan255GB-04

今度は400GBのvmdkファイルです。同じくFTT=1のストレージポリシーですが、RAID 0で構成された3つのコンポーネントで分割されています。この例ではすべて同じESXiホストに格納されていますね。(ESXiホストが4台しかないことも原因だったかもしれません)