Part2：vROps バージョン 8.0でできること②

日本ヒューレット・パッカード株式会社の中川明美です。
今回はアプリケーションの管理と新たなトラブルシューティング機能についてご紹介します。
アプリケーションの管理機能として、vROps 7.5で「アプリケーションの監視」、vROps 8.0で「サービスの検出」が追加されました。トラブルシューティング機能として、トラブルの原因を分析するための情報を1つのダッシュボードで提示する「Workbench」が8.0で提供されています。

-Back Number-

#1：vROps バージョン 8.0でできること①
#2：vROps バージョン 8.0でできること②
#3：ユーザーインターフェースの変更いろいろ
#4：スーパーメトリックもウィザードを強化
#5：アプリケーションの管理
#6：Workbenchのトラブルシューティング
#7：vROps 8.0のｖSANダッシュボード/SDDCコンプライアンス

このパートで、3つの機能を簡単にご紹介します。詳細な内容は後続のパートで！

◆アプリケーションの監視◆

「アプリケーションの監視」では、vRealize Application Remote Collectorでサポートされるオペレーティングシステムおよびアプリケーションサービスを監視します。
関連するアプリケーションのメトリックを確認しながら、仮想インフラのトラブルシューティングを行ったり、アプリケーションの管理者と収集した情報を共有することができます。
Advanced エディションではオペレーティングシステムを、Enterprise エディションではオペレーティングシステムおよびアプリケーションサービスの監視を行うことができます。

ホームの「アプリケーションの監視」の画面です。
この画面から、「検出された」「サポートされている」、オペレーティングシステムおよびアプリケーションサービスを確認することができます。
vROps 8.0で、NTPD、Java、Websphereが追加されています。

サポートされているオペレーティングシステムおよびアプリケーションサービスの詳細は次のドキュメントをご確認ください。

▼サポートされるオペレーティングシステムおよびバージョン
https://docs.vmware.com/jp/vRealize-Operations-Manager/8.0/com.vmware.vcom.config.doc/GUID-E2BBA2B8-A03A-4FB3-B408-E7D67C7B1C60.html

▼サポートされるアプリケーションサービスおよびバージョン
https://docs.vmware.com/jp/vRealize-Operations-Manager/8.0/com.vmware.vcom.config.doc/GUID-EBDE39E0-027F-4A41-A596-08E52E2D17EE.html

Microsoft IISの「Web Services」のメトリックを表示した画面です。
vROpsを使用して、アプリケーションサービス、サービスが稼働するゲストOS、仮想マシン、ESXiホストのメトリックを並べて表示できますから、どこに問題が発生しているかを特定する際、煩雑さの軽減や時間短縮ができそうですね。

◆サービスの検出◆

「サービスの検出」では、各仮想マシンで実行されているサービスを検出し、異なる仮想マシンのサービス間の関係または依存関係を監視するのに役立ちます。サービスの検出で得た情報から、サービスの一部である仮想マシン、仮想マシンのシャットダウンまたは移動の影響、インシデントの影響を確認できます。
Advancedエディション以上で、サービスの検出および監視を行うことができます。

ホームの「サービスの検出」の画面です。
この画面から、「検出された」「既知の」サービスを確認することができます。

サポートされる製品バージョンやオペレーティングシステムバージョンの詳細は次のドキュメントをご確認ください

▼サービス検出がサポートしているプラットフォームと製品
https://docs.vmware.com/jp/vRealize-Operations-Manager/8.0/com.vmware.vcom.config.doc/GUID-81922676-399B-4A05-A3AF-723CC804D197.html

ホーム-「サービスの検出」で、検出されたサービスの「仮想マシン」リンク文字列をクリックすると、管理-「インベントリ」-「サービスの管理」画面が表示されます。この画面から該当のサービスが稼働している仮想マシンを調べることができます。

アプリケーションの監視と同様に、検出されたサービスのメトリックも表示することができます。IISサービスは「パフォーマンス」のメトリックが準備されています。

◆Workbench◆

「Workbenchトラブルシューティング」では、「潜在的な証拠」が特長的です。ここから、既知の問題と未知の問題の両方を調査することができます。
「潜在的な証拠」タブでは、「イベント」「プロパティの変更」「アノマリのメトリック」が表示されます。ある時間(デフォルト2時間半)にどのような操作が実行され、どのような変更がなされ、また大幅に変化したメトリックがあるかを確認できます。トラブル予防としても活用できそうです。

画面左上の「選択されたスコープ」も役立つ機能かと思います。レベルを変更し、監視するオブジェクトの範囲を広げたり、狭めたりし、関連オブジェクトを表示します。
下図は、スコープをレベル1からレベル4に変更した後の関連オブジェクトです。警告 (赤い●) が表示されているのはESXiホストですが、広い範囲で分析したい時は、スコープを変更し、該当オブジェクトの詳細画面へ遷移することもできます。

◆まとめ◆

vROps 8.0で提供される「サービスの検知」を使用すると、仮想マシン上でどんなサービスが稼働しているかを知ることができるのはよいですね。インフラチームとアプリケーションチームが異なる場合、事前に情報共有が徹底されるのがベストですが、難しい場合もありますよね。
vROps 7.5から提供されている「アプリケーションの監視」は、アプリケーション固有のメトリックが準備されていますから、アプリケーションチームが必要な情報を提供できますね。
「Workbench」も活用できそうです。私はLab環境の運用管理も担当していますから、Workbenchを使ってトラブルシューティングをしてみました。表示された情報から、vSphere 6.7 U3のKBを見つけました。vSphere Clientからは得られない情報でした。このKBを含め、後続のパートで事前に確認すべきことや必要な設定等をご紹介します。

The post vROps 8.0はオンプレミスからクラウドまで appeared first on Japan Cloud Infrastructure Blog.

Part3：ユーザーインターフェースの変更いろいろ

日本ヒューレット・パッカード株式会社の中川明美です。
今回は、Part3の「ユーザーインターフェースの変更いろいろ」です。
vROps 7.5から、カスタムダッシュボードの作成方法がアップデートされています。ウィジェット間の関係を指定する方法が容易になりました。ドラッグ操作で視覚的に設定できます。
このPartでは、復活した「ワークロード」タブ、メトリックを使用したカスタムダッシュボードの作成を例に進めます。

-Back Number-
#1：vROps バージョン 8.0 でできること①
#2：vROps バージョン 8.0 でできること②
#3：ユーザーインターフェースの変更いろいろ
#4：スーパーメトリックもウィザードを強化
#5：アプリケーションの管理①
#6：アプリケーションの管理②
#7：Workbench のトラブルシューティング
#8：vROps 8.0 の vSAN ダッシュボード/ SDDC コンプライアンス

◆ワークロード◆

「ワークロード」タブが復活しました！！！
「CPU」と「メモリ」の構成サイズ(キャパシティ)が妥当であるかを分析する最初のステップとして使用していたため、うれしい限りです！
メモリのワークロードの内訳の数値は、「消費」から「デマンド」へ変更されています。

上図は「クラスタ」オブジェクトを選択したワークロード画面です。
クラスタのデマンドは80%を超え、赤色の警告表示になっています。しかしすべての仮想マシンのデマンドが高い値を示しているわけではありません。仮想マシンのメモリ構成サイズが適正サイズより大きい場合、このような結果になることがあります。エンドユーザー様の環境でもよく見かけるメモリ状況です。
仮想マシンのメモリサイズを最適な値に変更すれば、クラスタのデマンド値や使用量を下げることができます。

低パフォーマンスの仮想マシンの誤ったチューニング例をご紹介します。
クラスタやホストのメモリ使用量から、低パフォーマンスの原因をメモリと判断し、「ホストのメモリ増設」＆「仮想マシンのメモリ割り当て追加」があげられます。しかし、仮想マシンやゲストOSまで視点を広げると、仮想マシンのメモリサイズは十分であり、CPU数が原因だったということもあります。
今回の例のように、クラスタのデマンドは高い状態であっても、デマンドが高くない仮想マシンが存在する場合は、それらの仮想マシンを最適なメモリサイズへ変更することを検討ください。
仮想マシンを最適なメモリサイズに変更してホストのメモリ使用量が下がれば、パフォーマンスに影響を与えることなく、メモリリソースの最適化が可能です。

ここからは、1つの仮想マシンをフォーカスし、詳細に分析してみます。下図(赤色点線枠)から、「キャパシティ(メモリ構成サイズ)」「デマンド」「使用量」を比較します。この仮想マシンは「4GB」でメモリを構成しています。デマンド値は「3.49GB」です。過去6週間の平均使用量は「774.68MB」です。
仮想マシンはデフォルトでは実際の物理メモリ使用量に関わらず、構成(最大)サイズまで要求することが可能です。仮想マシンのデマンドに応じて、物理メモリが割り当てられるため、クラスタ(またはホスト)の使用率が高くなる傾向があります。

次に、「ゲスト使用量」「ゲストデマンド」「mem.standby.normal_latest」のメトリックを使用して、仮想マシンのメモリサイズが適正であるかを比較検討してみます。ゲストOSは、一般的なOSとアプリケーションの関係とは異なり、割り当てられた物理メモリを解放せず、最近使用していないメモリをフリーリストに移動します。物理メモリ不足時には、バルーニングによって、GuestOS未使用のメモリは再利用されます。
仮想マシンの「ワークロードのメモリ使用量」と「ゲスト使用量」の値は次の通りです。収集期間や計算方法は異なりますが、仮想マシンのワークロードのメモリ使用量 (約775MB) と、ゲスト使用量(最高値と最低値の平均値 は約754MB) は近い値です。仮想マシンが使用している物理メモリが、ゲストOSに割り当てられていることがわかります。

・仮想マシンのワークロードのメモリ使用量：774.68MB　※過去6週間の平均値
・ゲスト使用量： 809, 052.81KB (約790MB)　※過去7日間の最高値

「ゲスト使用量」と「ゲストデマンド(要求値)」を比較すると、ゲストデマンドはゲスト使用量の半分未満です。これらの値から、ゲストOSは割り当てられた物理メモリの半分も要求していないことがわかります。

・ゲストデマンド：322,784KB (約315MB)　※過去7日間の最高値

mem.standby.normal_latestの値を確認します。「ゲスト使用量」の半分近くあります。この値から、割り当てられた物理メモリの半分ほどが最近未使用であることがわかります。

・standby.normal_latest：415,732.28 (約406MB)　※過去7日間の最高値

これらの状況から、4GBのメモリの構成サイズを減らせるのではないかと検討できます。
継続的な監視を前提に、仮想マシンやゲストOSのメトリックから判断すると、たとえば1GBまで減らせるのではないでしょうか。仮想マシンの構成サイズを4GBから1GBへ変更すると、仮想マシンのデマンド(3.49GB)も減りますから、ホストの使用量を抑えられそうですね。

話は変わりますが、メトリックの画面上部にオブジェクトの関係性が表示されるようになりました。
また、以前は最近未使用のフリーリストの値を監視するために、「空きメモリ(上図の赤点線枠)」を使用していましたが、vRealize Application Remote Collectorによって収集される「standby.normal_latest」の方がより正確な値が得られそうですから、こちらを使用しました。

◆カスタムダッシュボード◆

「ダッシュボードの作成」では、最初にダッシュボードを構成するパーツをドラッグします。
画面右下から「ウィジェット」または「ビュー」に切り替え、パーツを追加することができます。

ここから、適正サイズを分析するためのダッシュボードを作成してみようと思います。
「オブジェクトリスト」で選択した仮想マシンの「メモリ」と「CPU」のメトリックを表示します。

ダッシュボード作成時には、メトリックの単位を変更することができます。
メモリは「KB」から「GB」へ、CPUは「KHz」から「GHz」へ変更しました。残念ながら、「standby.normal_latest」メトリックは変更することができませんでした。

▼相互作用

相互作用は、矢が付いているアイコンから、連携したいウィジェットにドラッグします。この設定により、リストで選択したオブジェクトに関するメトリックが表示されます。
できない操作は、ドラッグ後の線が表示されませんから、設定ミスを防ぐこともできます。オブジェクトリストの矢が付いていないアイコンからドラッグしても、線は表示されません。

▼「仮想マシンキャパシティ」の確認

「仮想マシンリスト」で選択した仮想マシンの「CPU」および「メモリ」のメトリックが表示されるカスタムダッシュボードが作成できました。

適正な構成サイズ(キャパシティ)は、デマンド値を参考に比較検討します。

【メモリ】
表示された期間の使用量のMAX値は約2.5GB、デマンドは0.5GB程度です。使用量よりデマンド値は低く、フリーリストにもメモリがある状況です。デマンド値を参考に1GBまで減らしたとしてもゲストOSの要求は十分に満たせそうです。構成サイズを減らす変更が心配なら、仮想マシンの設定の編集で「制限」を利用し、しばらく監視するのもよいかもしれません。
「構成サイズ」より「デマンド」が高い場合はメモリの追加を検討します。「デマンド」より「使用量」が低い場合は競合の発生を疑います。

【CPU】
CPUはデマンドおよび使用量も、物理コアの性能(2.2GHz)を上回っていませんから、現在の1vCPUで問題なさそうです。「デマンド」が性能を上回る場合は、vCPUの追加を検討します。

◆まとめ◆

vROpsは、Advanced以上のライセンスがあればダッシュボードのカスタマイズできますから必要な情報を限定して表示することができますね。また、vRealize Application Remote Collectorで収集されるゲストOSのメトリックを使用すれば、仮想マシンとゲストOSのデータを比較することも可能です。より確かな分析ができますね。
カスタム作成は以前のバージョンと比べ容易になってきましたから、ご自身の環境に合わせ準備頂けると、vROpsをより活用できると思います。
次回はスーパーメトリックの作成方法をご紹介します。スーパーメトリックの作成も簡単になりましたよ。

The post vROps 8.0 はオンプレミスからクラウドまで appeared first on Japan Cloud Infrastructure Blog.

Part4：スーパーメトリックもウィザードを強化

日本ヒューレット・パッカード株式会社の中川明美です。
今回は、Part4の「スーパーメトリックもウィザードを強化」です。
vRealize Operationsでは「メトリック」を構成(作成)する方法が複数あります。今回は「メトリック構成」と「スーパーメトリック」をご紹介します。どちらも「管理」メニューの「構成」から始めます。vROps 7.5から、スーパーメトリックはウィザード(アシスト)機能が強化されています。
「メトリック構成」のメトリックはダッシュボードのウィジェットを使用し、「スーパーメトリック」は「環境」メニュー内でデータ表示します。

ｰ Back Number ｰ
#1：vROps バージョン 8.0でできること①
#2：vROps バージョン 8.0でできること②
#3：ユーザーインターフェースの変更いろいろ
#4：スーパーメトリックもウィザードを強化
#5：アプリケーションの管理①
#6：アプリケーションの管理②
#7：Workbenchのトラブルシューティング
#8：8.0のｖSANダッシュボード/SDDCコンプライアンス

「メトリック構成」からご紹介します。

◆メトリック構成◆

「メトリック構成」は、「管理」メニューから、メトリック用の新規XMLファイルを作成することもできますし、既存のメトリックを活用することもできます。既存のメトリックを活用することから始め、メトリック構成(作成)に慣れるのもお勧めです。

▼既存メトリックの使用事例

下図は、「VMのトラブルシューティング」ダッシュボードの編集画面です。
組み込みの「VMのトラブルシューティング」ダッシュボードでは、既存の「Dash-VM-Troubleshooting-Utilization」が使用されています。

▼Dash-VM-Troubleshooting-Utilizationの内容確認

メトリックのXMLファイルの内容から、CPUのしきい値を確認できます。黄色は「警告レベル」、オレンジ色は「緊急レベル」、赤色は「クリティカルレベル」を示します。

ダッシュボードを確認すると、CPUは指定された%(しきい値)に線が引かれています。
メモリのしきい値はメトリックの構成で指定していませんが、おそらく、「アラート」メニューの「アラート設定」-「シンプトンの定義」の仮想マシンのメモリワークロードの値が反映されているように思われます。仮想ディスクとネットワークは、ワークロードのシンプトンがありませんから、しきい値の線は表示されていないようです。しきい値に関してはドキュメントに明示的な記述がありませんからこれらは推測です。
メモリや仮想ディスク等のしきい値を設定したいのであれば、「管理」メニューの「構成」-「メトリック構成」で、「Dash-VM-Troubleshooting-Utilization」メトリックの内容をコピー元にして、カスタムメトリックを作成してみてください。

次に、「スパーメトリック」をご紹介します。

◆スーパーメトリック◆

スーパーメトリックは、１ つ以上のメトリックを含む数式であり、ユーザー自身が設計するメトリックです。メトリックの組み合わせを単一のオブジェクトまたは複数のオブジェクトから追跡する必要がある場合に使用します。1 つのメトリックで監視できない場合、スーパー メトリックで定義します。
こちらは、後でご紹介するサンプルのスーパーメトリック「Put Host System child and parent ResourceKinds in alert blackout when host is in Maintenance Mode」です。メトリックの説明文を読むと、ResourceKindから発生する、vROps内のアラートを自動的に制御するメトリックだそうです。メンテナンス時のアラート表示を制御しています。
「depth」は階層を表します。例えばこのスーパーメトリックをESXiホストに適用した場合、depth=0ならESXiホストを対象とします。1なら仮想マシン、-1ならクラスタ、-2ならデータセンターです。負の値は子オブジェクトの親を対象とする場合に使用します。スーパーメトリックでは、このサンプルのように複数のオブジェクトを定義することができます。

※このメトリックをvROps 8.0で使用するには、式の編集が必要です。

ここからは、アシスト機能を使用して、1台のホスト上の全Guest OSのメモリデマンドの平均値を表示するスーパーメトリックを作成します。

▼新規スーパーメトリックの作成

「管理」メニューの「構成」-「スーパーメトリック」で、「新規スーパーメトリックの作成(緑の十字のアイコン)」をクリックします。

「基本情報」で名前や説明を入力し、次の「数式の作成」でメトリックの数式を構成します。「関数」のリストから「avg」を選択します。

「avg()」の()内にマウスカーソルを移動し、「Ctrl + スペース」を押します。「アダプタタイプ」→「vCenter Server アダプタ」→「仮想マシン」の順に選択します。()内で「仮想」と入力後、「Ctrl + スペース」を押し、「仮想マシン」を表示することも可能です。

(仮想マシン：　)のセミコロンの右にマウスカーソルを移動し、「Ctrl + スペース」を押します。リストから、「メトリック」→「メモリ|ゲストデマンド(KB)」の順に選択します。

「プレビュー」で、任意のホストを選択し、内容を確認します。

「オブジェクトタイプへの割り当て」で、どのオブジェクトを選択したら、作成したスーパーメトリックが表示されるかを選択します。ここでは vCenter Server アダプタ の ホストシステム を選択しました。

最後にこのスーパーメトリックをポリシーで有効にします。ここではデフォルトのポリシーで有効にしました。

▼スーパーメトリックの表示

「環境」メニューでESXiホストの「メトリック」を選択します。「プレビュー可能なスーパーメトリックの表示」アイコンをクリックします。

作成したスーパーメトリックを右下の画面に表示(ダブルクリックまたはドラッグ)します。
画面上のオブジェクトで「仮想マシン」をダブルクリックすると、選択したESXiホスト上の仮想マシン名を確認することもできます。

▼スーパーメトリックを拡張する

今回作成したスーパーメトリックはシンプルなものですが、where句を追加して同じオブジェクトの異なるメトリックを参照することもできます。where句の例はドキュメントの「スーパーメトリックを拡張する」で確認できます。

https://docs.vmware.com/jp/vRealize-Operations-Manager/6.7/com.vmware.vcom.config.doc/GUID-2290A3B5-3C4B-4EA8-BB52-B0C7DFE7458B.html

◆vRealize Operations Sample Exchange◆

最後に「vRealize Operations Sample Exchange」をご紹介します。

https://vrealize.vmware.com/sample-exchange/

このサイトから、カスタムダッシュボードやスーパーメトリックのサンプルをダウンロードできます。サードベンダーのサンプルもあります。ダウンロードしたサンプルをインポートして、活用するのもよさそうですね。

◆まとめ◆

今回はメトリックを中心にご紹介しました。既存のメトリックを活用したり、新規のメトリックを作成したり、複数の方法でカスタムメトリックを構成できます。ダッシュボード作成時にメトリックを作成することもできます。
運用をメインにされているエンジニアの方には、Logと同様にメトリックは、「いつ」「何が起きた/起きている」は重要な情報ですよね。メトリックの画面から、各オブジェクトの関係性も確認できますから、関係するオブジェクトに問題が起きているのでは？とあたりをつける場合にも活用できます。次は「アプリケーションの管理」です。前提条件の確認が必須です！！

The post vROps 8.0 はオンプレミスからクラウドまで appeared first on Japan Cloud Infrastructure Blog.

トレンドマイクロ VMware テクニカルアライアンス担当 栃沢です。

昨年 VMware NSX-T^® Data Center（以降 NSX-T Data Center）環境での DSVA の展開が可能となる Deep Security 12.0 がリリースされ、すでに導入を頂いているお客様も多くいらっしゃいます。ご要望を多くいただいていた日本語版のインテグレーションガイドをリリースいたしましたのでお知らせします。

[White Paper]
VMware NSX-T Data Center & Trend Micro Deep Securityインテグレーションガイド
～エージェントレスセキュリティとマイクロセグメンテーション～
NSX-T2.4-2.5.0+DSVA12.0_IntegrationGuide_Rev1.0a

NSX-T Data Cener 環境における Deep Security での対応については、Deep Security 12.0 のアップデートに関する記事で既にご紹介しておりますので、そちらをご参照頂きたいと思います。

1. Deep Security 12.0 リリース内容とVMwareソリューション関連のアップデート
2. Deep Security 12.0 VMware NSX-T環境におけるエージェントレス型セキュリティの実装概要
3. DSVAシームレスアップデートによるアップデートの簡素化

このインテグレーションガイドでは、VMware NSX Data Center for vSphere (以降 NSX for vSphere) との仕様の違いや留意点、サイジングの考え方などについても記載をしています。
NSX-T 環境特有の仕様や留意点などもありますので、提案、設計、導入の前には必ず一読を頂ければと思います。

また、NSX-T 2.5.0 環境、NSX-T 2.5.1 (年明けに対応) においては、以下のブログにも記載させて頂いている NSX-T 2.5 以降の Guest Introspection Service の仕様変更と制約事項があります。DSVA のデプロイにあたり必ずチェックしておくべき点ですので、本インテグレーションガイドと併せて以下の記事についてもご参照ください。

1. VMware NSX-T Data Center 2.5環境におけるTrend Micro Deep Security Virtual Appliance（DSVA）デプロイに関する留意事項
2. VMware社 KB：Using the correct untar tool and appropriate MIME types for NSX intelligence (74962)

ぜひ、こちらのインテグレーションガイドをご活用ください。

執筆者：

トレンドマイクロ株式会社
エンタープライズSE本部
セールスエンジニアリング部 ネットワークセキュリティチーム
シニアソリューションアーキテクト / VMware vExpert
栃沢 直樹（Tochizawa Naoki）

The post VMware NSX-T Data Center & Trend Micro Deep Securityインテグレーションガイドのリリース appeared first on Japan Cloud Infrastructure Blog.

Part8：vROps 8.0 のvSANダッシュボード/SDDCコンプライアンス

日本ヒューレット・パッカード株式会社の中川明美です。
今回は、「vROps 8.0 の vSAN ダッシュボード/ SDDC コンプライアンス」です。バージョン 8.0 のvSAN 連携の変更点、およびセキュリティコンプライアンスについてご紹介します。「コンプライアンス」機能は、セキュリティ構成ガイドを元に監視します。

-Back Number-
#1：vROps バージョン 8.0でできること①
#2：vROps バージョン 8.0でできること②
#3：ユーザーインターフェースの変更いろいろ
#4：スーパーメトリックもウィザードを強化
#5：アプリケーションの管理①
#6：アプリケーションの管理②
#7：Workbenchによるトラブルシューティング
#8：vROps バージョン8.0のvSANダッシュボード/SDDCコンプライアンス

◆環境について◆

この Blog では次のバージョンの VMware 製品を使用しています。vSAN クラスタは仮想マシンのESXiホストで構成しています。

• VMware-VCSA-all-6.7.0-15132721.iso
• VMware-VMvisor-installer-6.7.0.Update03-14320388.x86_64.iso
• vRealize-Operations-Manager-Appliance-8.0.1.15331180_ovf10.ova

◆vSAN アダプタインスタンスの構成◆

vRealize Operations (vROps)  8.0では、vSAN アダプタインスタンスの構成方法が変更されました。次の手順でvSANアダプタインスタンスを構成します。

1. 「管理」メニューの「クラウドアカウント」ページで、vCenter Server のインスタンス (この環境のインスタンス名は「vCenter Server」と指定) をクリックし、「vSAN」タブを選択します。
2. 「vSAN 構成」オプションを右に移動し、有効にします
3. 「SMART データ収集を有効にする」を選択します。
4. 「接続をテスト」をクリックし、vCenter Server インスタンスへの接続を検証します。
5. 「保存」をクリックします。

「その他のアカウント」に vSAN アダプタインスタンスが追加されます。vSAN アダプタインスタンス構成直後はステータスが「警告」表示されます。問題なければその後「OK」と表示されます。

◆データ収集の確認◆

vSAN アダプタ インスタンスを構成後、「管理」-「インベントリ」-「アダプタ インスタンス」-「vSAN アダプタインスタンス」で、データが収集されているかを確認します。
リスト右側の「収集ステータス」が緑色の場合はアダプタがオブジェクトからデータを取得しています。vSAN のオブジェクトタイプが表示されるまでしばらくかかります。
2つの緑色アイコンの右側は vCenter Server アダプタ配下のオブジェクトの収集ステータスです。

詳細はこちらのドキュメントを参照ください。

<アダプタ インスタンスが接続済みでデータを収集していることを確認する>

https://docs.vmware.com/jp/vRealize-Operations-Manager/8.0/com.vmware.vcom.config.doc/GUID-5D106B51-4587-41C7-A206-CF655B3E9B32.html

◆vROps の vSAN ダッシュボード◆

以前(6.7)のバージョンと比べて、大きな変更点はありません。
vSAN の監視に必要な、4つのダッシュボード (赤色枠内) が提供されています。

「vSAN のトラブルシューティング」ダッシュボードの右上に表示されている「アラート (赤色点線枠内) 」に注目します。
「ホスト上の CIM サーバが動作していません」アラートは、vSAN クラスタに追加している ESXi ホストが仮想マシンのため表示されています。
他に ESXi ホストや vSAN キャッシュディスク/キャパシティディスクの「vSphere セキュリティ設定ガイドに違反しています」アラームが表示されています。暗号化の設定がなされていないことが原因です。セキュリティの監視が強化されていますね。

vSAN の暗号化を設定するには、vSphere Client からキー管理サーバ (KMS) を vCenter Server システムに追加後、vSAN サービスの設定で暗号化を有効にします。

<KMS クラスタの設定>

https://docs.vmware.com/jp/VMware-vSphere/6.7/com.vmware.vsphere.virtualsan.doc/GUID-1583A645-07EE-4D26-8698-080283694635.html

◆vCenter 内の vROps◆

vSphere Client 内で表示される vROps の情報も以前のバージョンから変更はありません。

◆SDDC コンプライアンス◆

「コンプライアンス」機能で、セキュリティ構成ガイドに準拠しているかを確認することができます。
vSphere / VMware Cloud on AWS / vSAN 6.7、6.5、6.0 / NSX-T 2.3、2.4、2.5 / NSX-V 6.3.x、6.4.xオブジェクトのコンプライアンスを確保するために、vROps 8.0.1では、VMware vSphere セキュリティ設定ガイド「バージョン 6.7 Update 1、6.5、6.0」用のコンプライアンスアラートが含まれています。ガイドの詳細内容は次の URL からご参照ください。

https://www.vmware.com/security/hardening-guides.html

こちらは、vSphere 6.7 Update 1 のセキュリティ構成ガイドの一部です。どのような項目がリストアップされているのかを確認すると、セキュリティのベストプラクティスを知る機会になります。

「ホーム」-「コンプライアンス」で、セキュリティ設定ガイドとのコンプライアンスを確認します。「セキュリティ設定ガイド」は、「VMware 製品を安全に導入して操作する方法に関する規範的なガイダンス(赤色点線枠内)」であると表示されています。「VMC SDDC」タブで VMware Cloud on AWS の、NSX が環境に構成されていれば NSX のコンプライアンスが表示されます。「カスタムベンチマーク」を作成すれば、ご自身の環境に合わせて、アラートをカスタマイズすることもできます。「規制ベンチマーク」を使用すると、業界標準の規制コンプライアンスと準拠することもできます。

▼VMware SDDC ベンチマーク

「vSAN セキュリティ構成ガイド」の「編集」でポリシーを有効化し、評価を行います。
評価後、遵守/非遵守の内容を確認します。

先の「vSAN のトラブルシューティング」で表示されていたセキュリティに関するアラームを、コンプライアンスからも確認することができます。

▼カスタム ベンチマーク

「カスタムコンプライアンスの追加」で、ご自身の環境に合わせて表示するアラートを選択することができます。

◆まとめ◆

vCenter Server で提供される vSAN の監視機能でも必要なパフォーマンス情報を得られますが、vROps を使用するメリットとして、仮想基盤全体を監視できること、必要な情報をカスタマイズ表示できることが挙げられます。
vSAN のデータストアはサーバーのローカルディスクで構成されますから、コンピューティングリソースは必要な監視対象です。また後半でご紹介したコンプライアンス機能を使用すれば、セキュリティ視点で安全な構成かどうかを監視できるのも大事な要素かと思います。
vROps はクラウドとも連携できますし、SaaS 製品としても提供されますから、vROps の活用の幅が広がりそうです。
vROps 8.0に関する本 Blog は Part8 で完了です。仮想基盤のキャパシティやパフォーマンスの課題にどのように対処するかを、こちらの Blog を参考にしていただければ幸いです。
この度もお読みいただき、ありがとうございました。

The post vROps 8.0はオンプレミスからクラウドまで Part 8 appeared first on Japan Cloud Infrastructure Blog.

Part7：Workbench によるトラブルシューティング

日本ヒューレット・パッカード株式会社の中川明美です。今回は、vRealize Operations (vROps) 8.0 から提供された「Workbench」によるトラブルシューティングをご紹介します。
「アラート」「メトリック」「イベント」に、新たに「潜在的な証拠」を加え、トラブルシューティングに必要な情報を1つのダッシュボードに収めたものが「Workbench」です。

-Back Number-
#1：vROps バージョン 8.0でできること①
#2：vROps バージョン 8.0でできること②
#3：ユーザーインターフェースの変更いろいろ
#4：スーパーメトリックもウィザードを強化
#5：アプリケーションの管理①
#6：アプリケーションの管理②
#7：Workbenchによるトラブルシューティング
#8：vROps 8.0のｖSANダッシュボード/SDDCコンプライアンス

◆トラブルシューティング「Workbench」ホームページ◆

「Workbench」ホームページは、「ホーム」または「クイックスタート」メニューの「トラブルシューティング」から表示します。
ホームページには、「検索バー」「アクティブなトラブルシューティング」「最近の検索」があり、「アクティブなトラブルシューティング」には、現在のログインでアクティブなセッションが表示されます。次回  vROps にログインした時に、以前「アクティブなトラブルシューティング」に表示されていたセッションは、「最近の検索」に表示されます。
ホームページに表示される日時は対象オブジェクトの Workbench を起動した日時です。いずれかをクリックすると、「Workbench のトラブルシューティング」が表示されます。

◆Workbench によるトラブルシューティング◆

「Workbench」トラブルシューティングは、「潜在的な証拠」「アラート」「メトリック」「イベント」のタブで構成されます。
「潜在的な証拠」では、「イベント」「プロパティの変更」「アノマリのメトリック」が表示されます。

▼イベント

通常の動作から逸脱したメトリックのイベントと、選択したスコープおよび時間内に発生した主要イベントが表示されます。

▼プロパティの変更

選択したスコープおよび時間内に発生した重要な構成変更が表示されます。

▼アノマリのメトリック

選択したスコープおよび時間内に大幅に変化したメトリックを表示します。

上図で、「潜在的な証拠」の時間の範囲は「19/11/06 10:40 – 19/11/06 13:10」と表示されています。ここでは ESXi ホストで異常を検知した日時です。メモリのプロパティ変更時 (2019/11/06 10:57:26) の情報と、10:40～13:10 の間に起きたアノマリのメトリック (大幅に変化したメトリック) が表示されています。この時間に、vRealize Application Remote Collector をインストールしたため、メモリとディスクに大幅な変化があったと検知されたようです。

「プロパティの変更」や「アノマリのメトリック」内の「メトリックにチャートを追加」(緑色の枠内のピンのアイコン)をクリックすると、該当のメトリックが「メトリック」タブ内に表示されます。下図は、過去30 日間のデータに変更し、表示しています。11/6 に「ランタイム｜メモリキャパシティ」は約 52GB まで増え、その後 11/15 12:27 までに 43GB まで下降し、11/15 13:52 で52GB に上昇しています。その後はデータがありません(この状態が維持されています)。この環境では、11/6 にインストールし、11/15 からこのブログを書くために vROps に接続を開始しました。今回の「潜在的な証拠」で表示されているデータは、原因が明らかですから、トラブルに発展することはなさそうです。このように未知の問題を調査する場合に「潜在的な証拠」は有効です。

◆「潜在的な証拠」画面の変更◆

Part2 でもご紹介しましたが、「時間範囲」や「スコープ」を変更することができます。「潜在的な証拠」のスコープや時間等に加えた変更は、ログアウト時に保存されません。

▼時間の範囲
デフォルトの時間範囲は 2 時間半です。最大過去7日間まで時間範囲を選択できます。

▼選択されたスコープ

「レベル1」から「レベル4」まで変更すると、データセンターおよび vCenter Server まで選択できる範囲を拡張できます。広い範囲で分析したい場合に便利ですね。

▼ポップアウト

「アノマリのメトリック」で「ポップアウト(緑色枠内)」アイコンをクリックすると、詳細画面が表示され、メトリックの画面同様の操作が行えます。

◆オブジェクトから Workbench の起動◆

運用時は、「ホーム」メニューから Workbench を起動するというよりは、オブジェクトのアラートを見つけた際、画面右上の「トラブルシューティング」から起動する方が活用できそうです。
オブジェクトの画面から Workbench を起動し、既知の問題または未知の問題を調査するのがスムーズな方法だと思います。

◆「Hardware sensor health state degraded. Sensor information」アラート◆

表示されているアラートが気になり、調べたところ次のKBを見つけることができました。
Excessive Hardware health alarms being triggered for “Sensor -1 type” on ESXi hosts running vSphere 6.7 U3 (74607)
https://kb.vmware.com/s/article/74607

「Impact / Risks」に、「ハードウェアの問題を示していない」「vCenter データベースのサイズが大きくなり、ディスク容量が不足する問題が発生する可能性がある」とありましたから、KB にしたがって、このアラートを表示させないように設定変更をしました。
vCenter Server の管理ツールではハードウェアの健全性は正常でアラートも表示されていなかったため、、vROps のこのアラートは何だろうとドキドキしていたのですが、大事に至らずホッとしました。
vSphere 6.7 U3 をお使いの方は、KBの内容をご確認ください。

◆まとめ◆

Workbench が追加され、既知の問題と未知の問題の両方を調査できるようになりました。
Workbench を起動すれば、トラブルシューティングに必要な情報が一画面で収集できますから迷う必要がないですね。vRealize Operations (vROps) のユーザーさんから、情報が多過ぎて、どこを見たらよいかのかわからないとご相談されることがあります。アラートが表示されていたら、最初にWorkbenchを 起動してみてください。「アラート」メニューからも Workbench を起動できます。
私は vSphere 6.7 U3 の KB が見つかり、vROps を活用できたなぁと喜んでおります(笑)
次回は、「vROps 8.0の vSAN ダッシュボード/SDDC コンプライアンス」です。

The post vROps 8.0はオンプレミスからクラウドまで Part 7 appeared first on Japan Cloud Infrastructure Blog.

Part5：アプリケーションの管理①

日本ヒューレット・パッカード株式会社の中川明美です。
今回は、「アプリケーションの管理①」です。
vRealize Operations (vROps) もアプリケーションやサービスの監視が強化されてきましたね。以前のパートでふれましたが、仮想基盤の知識を習得するために、私が実施するコースへアプリケーションエンジニアの方が受講されることが増えました。インフラとアプリケーション両方に見識がある方は比較的少ないように思われるため、インフラ視点でアプリケーションの監視視点も持てたら貴重な存在になりそうですね。仮想基盤とアプリケーションの監視が可能な vROps を活用して、適切な仮想基盤を運用いただけたらと思います。

ｰ Back Number ｰ
#1：vROps バージョン 8.0でできること①
#2：vROps バージョン 8.0でできること②
#3：ユーザーインターフェースの変更いろいろ
#4：スーパーメトリックもウィザードを強化
#5：アプリケーションの管理①
#6：アプリケーションの管理②
#7：Workbenchによるトラブルシューティング
#8：vROps 8.0のｖSANダッシュボード/SDDCコンプライアンス

vROp 7.5 から「アプリケーションの監視」、8.0 から「サービスの検出」が提供されています。2つの機能は「ホーム」-「アプリケーションの管理」メニューの配下に表示されます。Part5 は、「アプリケーションの監視」の構成までをご紹介します。

◆アプリケーションの監視構成のプロセス◆

vROps でアプリケーションの監視を行うには、いくつかの事前準備があります。アプリケーションの監視が動作しない場合は、これらのステップが正しく行われたかを確認します。

「1」と「2」の手順は、次のドキュメントをご確認ください。

<VMware vRealize Application Management Pack のアクティベート>
https://docs.vmware.com/jp/vRealize-Operations-Manager/8.0/com.vmware.vcom.config.doc/GUID-978A9D73-3698-49E6-8E98-B4EC16D88D1B.html

<vRealize Application Remote Collectorのデプロイ>
https://docs.vmware.com/jp/vRealize-Operations-Manager/8.0/com.vmware.vcom.config.doc/GUID-7F1F910F-AFB9-493C-9CBF-DEFFF5E9BB69.html

◆vRealize Application Remote Collectorの構成◆

▼NTPの構成

「アプリケーションの監視」のポイントは「NTP 設定の構成」といってもよいかもしれません。
「vRealize Application Remote Collector」アプライアンスにログインし、/etc/ntp.conf にある ntp.conf ファイルへ NTP サーバーの情報を追加します。その後、NTPデーモンの起動 (systemctl start ntpd) および有効 (systemctl enable ntpd) を行います。
次に NTP が正しく構成されているかを「ntpstat」コマンドで確認します。正しく同期されている場合は、次のメッセージが表示されます。

同期されない場合は、「ntpdate」コマンドを実行するのも一つの方法です。
「エージェントのインストールに失敗する」「アダプタの構成に失敗する」場合の解決策として、「ntpdate」コマンドの実行があげられています。

https://docs.vmware.com/jp/vRealize-Operations-Manager/8.0/com.vmware.vcom.config.doc/GUID-98EC0EEA-337C-426A-9B5E-44C142F2A210.html

▼アプリケーションリモート コレクタの追加と構成

「管理」メニューの「アプリケーションリモートコレクタ」で、「アプリケーションリモート コレクタの追加と構成(緑色の十字アイコン)」をクリックします。

▼アプリケーションリモートコレクタの管理

1 アプリケーションリモートコレクタの構成

vRealize Application Remote Collector のインストール時に構成した vRealize Application Remote Collectorの完全修飾ドメイン名 (FQDN) と API 管理ユーザーのパスワードを入力します。

2 vCenter Server のマッピング

「vCenter Serverのマッピング」のドロップダウンメニューから、vCenter Server 名を選択します。vCenter Server 名が表示されたら、「テスト接続」をクリックします。vCenter Server 名の青色から緑色への変更は、vROpsが vRealize Application Remote Collector と通信できることを証します。

しばらく待つと(ステータスの取得までに最大5分)、アプリケーションリモートコレクタが追加表示されます。

◆エージェントのインストール◆

監視対象の仮想マシンにエージェントをインストールします。ここでは、Windows OSを対象とします。

<前提条件>

• vRealize Application Remote Collector、vROps、ESXｉ ホスト、監視対象の Windows および Linux の仮想マシンの間の時刻同期
• 仮想マシンにエージェントをインストールするためのゲスト操作権限
• ユーザーアカウント権限の前提条件　※ Windows は管理者権限
• 仮想マシンの構成要件　※ Windows は Visual C++ のバージョンが 14 以降であること

「管理」メニューの「インベントリ」-「エージェントの管理」で「インストール」アイコンをクリックします。ここでは、「VM19-1」仮想マシンにエージェントをインストールします。エージェントインストール後、再起動は発生しませんでした。

▼エージェントの管理

1 オプションの選択
すべての仮想マシンで共通のユーザー名とパスワードを使用している場合、「共通ユーザー名 & パスワード」を選択します。
すべての仮想マシンで異なるユーザー名とパスワードを使用している場合、「仮想マシンの認証情報を入力してください」を選択します。

2 認証上の提供
ユーザー名とパスワードを入力します。
すべての仮想マシンのユーザー名とパスワードが異なる場合、このページから CSV テンプレートをダウンロードし、そのファイルを適用します。

正常にインストールされると、「正常にインストールされました」と表示され、エージェントが実行されます。

◆アプリケーションサービスのアクティベーション◆

監視対象の仮想マシンで実行されているアプリケーションを監視するには、エージェントのインストール後に、対象仮想マシンで vRealize Application Remote Collector プラグインを構成(アプリケーションサービスのアクティベーション)する必要があります。
「管理」メニューの「インベントリ」-「エージェントの管理」で、対象の仮想マシンを選択し、「サービスの管理」アイコンをクリックします。ドロップダウンメニューからサービス名を選択します。ここでは、「msiis」を選択します。

「ステータス」を有効にし、表示名を入力後、保存をクリックします。
複数のインスタンスを追加する場合は、追加(緑色の十字アイコン)をクリックします。

正常に構成されたことを確認します。

<サポートされているアプリケーションサービスのバージョン>
https://docs.vmware.com/jp/vRealize-Operations-Manager/8.0/com.vmware.vcom.config.doc/GUID-EBDE39E0-027F-4A41-A596-08E52E2D17EE.html

◆まとめ◆

ゲスト OSおよびアプリケーションの監視は、構成の道のりが長いですね(笑)
私はLinux OS に触れる機会が少ないため、最初の山場は NTP の同期でした。こんなところで。。。と苦戦しておりました。また、ゲスト OS のメトリックは表示されるのに、サービスの管理でなぜアプリケーションサービスの「msiis」がメニューに表示されないのだろうと悪戦苦闘した結果、ライセンスエディションが Advanced だったという落ちです。
正常に稼働しない原因をさぐるために、久しぶりに Microsoft IIS の勉強をしてみたりと、よい機会だったと自分を慰めております(笑)
次回は、あらためてゲスト OS およびアプリケーション監視のメトリック画面とサービスの検出についてご紹介します。

The post vROps 8.0はオンプレミスからクラウドまで Part 5 appeared first on Japan Cloud Infrastructure Blog.

Part6：アプリケーションの管理②

日本ヒューレット・パッカード株式会社の中川明美です。
今回は、「アプリケーションの管理②」です。「アプリケーションの監視」で収集されるゲスト OSやアプリケーションサービスのメトリック、「サービスの検出」で各仮想マシンで実行されているサービスの検出方法およびメトリックについてご紹介します。

-Back Number-
#1：vROps バージョン 8.0 でできること①
#2：vROps バージョン 8.0 でできること②
#3：ユーザーインターフェースの変更いろいろ
#4：スーパーメトリックもウィザードを強化
#5：アプリケーションの管理①
#6：アプリケーションの管理②
#7：Workbench によるトラブルシューティング
#8：vROps 8.0 の vSAN ダッシュボード/ SDDC コンプライアンス

Part5 でアプリケーションの監視のための構成を終えましたから、Part6 では監視方法を確認します。

◆アプリケーションの監視◆

「ホーム」メニューの「アプリケーションの監視」で、検出されたオペレーティングシステムとアプリケーションサービスを確認することができます。「構成済み」と表示されていれば、監視可能です！

Microsoft IIS の「検出済み」のリンク文字列をクリックすると、「管理」メニューの「インベントリ」-「エージェントの管理」へ画面遷移します。
IIS サービスを検出した、「仮想マシン名」「オペレーティングシステム」「電源ステータス」「vCenter Server名」等がリスト表示されます。

▼オペレーティングシステムのメトリック

「環境」メニューから、各オブジェクトのメトリックを表示します。
ここでは、「すべてのオブジェクト」-「vCenter Server アダプタ」-「仮想マシン」を選択し、VM19-1仮想マシンの「CPU | 権限のある時間 (%)」と「システム | プロセッサ キュー長」を並べて表示しました。
もし、ゲスト OS の Processor Queue Length や使用率が常に高い状態なら、仮想マシンの「使用率」や「CPU Ready」を監視します。競合が発生しているなら、仮想マシンの移行を検討しなければなりません。メトリック画面で、「ゲスト OS」「仮想マシン」「ESXi ホスト」のメトリックを並べて分析すれば解決方法も早く導けそうです。並べて分析できるのが vRealize Operations (vROps) のよい点です。

▼Microsoft IIS のメトリック

ここでは、Web サービスのメトリックや上図と異なる画面構成を確認ください。左側のオブジェクトを選択するペインが異なりますね。
左ペインの「すべてのオブジェクト」の左側に「スイッチ」アイコン(緑色の点線枠内)があります。スイッチアイコンをクリックすると、「関連するオブジェクト」を選択するメニューに切り替わります。関連するオブジェクトを同時に監視したい時には、こちらの画面に切り替えてメトリックを追加する方が関係性がわかりやすそうですね。

<参考：アプリケーションサービスメトリック>
https://docs.vmware.com/jp/vRealize-Operations-Manager/8.0/com.vmware.vcom.config.doc/GUID-E3323920-C135-4174-9EC1-859264E7D154.html

◆サービスの検出◆

サービスの検出は、各仮想マシンで実行されているサービスを検出し、異なる仮想マシンのサービス間の関係または依存関係を確認するのに役立ちます。サービスが稼働する仮想マシンのシャットダウンや移行の際に、問題が起きないように適切な対応に備えることができます。
また、監視対象のサービスに基づいた基本メトリックの表示やサービス検出ダッシュボードを使用してサービスを監視することもできます。

▼サービス検出の前提条件

サービスの検出をするには、次の条件を満たします。

• vCenter アダプタインスタンスの構成
• サービスの検出やパフォーマンスメトリックの収集のためのコマンドまたはユーティリティが使用されていること
• ユーザーアカウント権限
• vCenter Server と仮想マシン間の時刻同期
• VMware Tools の実行　※KB75122 を参照

<参考：前提条件の詳細>
https://docs.vmware.com/jp/vRealize-Operations-Manager/8.0/com.vmware.vcom.config.doc/GUID-E02AF39E-748F-406B-9464-84DE826C82AC.html

▼サービス検出の構成

「ホーム」メニューの「アプリケーションの管理」-「サービスの検出」で、「サービス検出の構成」をクリックします。※下図は「サービスの検出」を有効にした後の画面です。

「クラウドアカウント」ページへ遷移します。vCenter Server インスタンスをクリックし、「サービス検出」タブを選択します。「サービス検出」 を有効にします。
デフォルトのユーザー名とパスワードを使用する場合は、Windows/Linux/SRM のデフォルトのユーザー名とパスワードを入力します。
この画面に、VMware Tools に関する KB 番号が表示されていますね。前提条件にあげましたが、「サービスの検出」の構成ポイントです！

▼サービスのメトリック

サービスの検出で、「仮想マシン」「サービスパフォーマンス」「サービス概要」「サービスタイプ」のメトリックを監視することができます。サービスの検出で収集される仮想マシンのメトリックでは、OOTB (out of the box) とユーザー定義(プロセス名とポート番号でホワイトリストを構成)のサービス数やサービスの送受信接続数を確認できます。

<参考：サービス検出メトリック>

https://docs.vmware.com/jp/vRealize-Operations-Manager/8.0/com.vmware.vcom.config.doc/GUID-3282DF19-194A-421C-B50F-A9AB5FB3D42B.html

◆まとめ◆

「アプリケーションの監視」と「サービスの検出」を比べると、今のところ検出できるサービス数は「サービスの検出」の方が多いです。また各機能の目的が異なるからでしょうが、「サービスの検出」で収集できるメトリックはインフラ寄りな内容ですね。
アプリケーションの実行に必要なパフォーマンスの提供可否を前提に、仮想基盤特有の仮想マシンや ESXi ホストのメトリックを分析すると解決に導く時間を短縮することができます。
アプリケーションとゲスト OS のパフォーマンス状況と仮想基盤のパフォーマンスやキャパシティを比較分析するのがポイントとなりますから、ぜひ vROp のアプリケーションの管理を活用いただけたらと思います。
サービスの検出やゲスト OS の監視は Advanced エディションから監視可能です。アプリケーションの監視は Enterprise エディションが必要ですから、お忘れなく！！

次回は、「Workbench のトラブルシューティング」です。

The post vROps 8.0はオンプレミスからクラウドまで Part 6 appeared first on Japan Cloud Infrastructure Blog.

皆様こんにちは！株式会社ネットワールドのDell EMC 製品担当です。

本日から計 5 回にわたり Dell EMC VxRail のご紹介とネットワールドの検証結果をご紹介していきたいと思います。

第一回は VxRail のおさらいをします。名前は知っているけど、知識があいまいなままになっている方は、ぜひこの機会に一緒に確認していきましょう！！

==本シリーズの目次==

■ 第 1回 : 今更聞けない！VxRail 基本のあれこれ

• コンセプト
• 3Tier との違い（HCI のメリット）
• VxRail が選ばれる理由

■ 第 2 回 : VxRail 管理画面ご紹介

■ 第 3 回 : All NVMe 対応の VxRail

■ 第 4 回 : ネットワールド的 検証結果報告 Part-1

■ 第 5 回 : ネットワールド的検証結果報告 Part-2

※検証結果の詳細については 3 回目の際に内容を発表しますのでお見逃しなく！

まずは【VxRail のコンセプト】をご紹介致します！

VxRail 最大の特徴は「vSphere 環境に最適化されたハイパーコンバージド」であること。VxRail はストレージ仮想化の VMware vSAN とハイパーバイザーの vSphere が一体化で構成されているため、非常にシンプルな処理ができ、他社の HCI 製品よりより多く仮想マシンを割り当てることができます。

そして基本コンセプトは簡単導入、簡単管理、簡単拡張の 3 つ！

1. 簡単導入

・サイジングや検証は VxRail のみ！

サーバー、ネットワーク、ストレージ、OS などを個別に調達するよりも、導入期間を大幅に短縮することができます。

2. 簡単管理

・日本語管理画面の「VxRail Manager」で一括管理！

vSphere 基盤のリソース状況やハードウェアのステータス状況などを一括して管理でき、仮想化基盤の運用管理を高めることができます。

3. 簡単拡張

・拡張作業は柔軟、しかも無停止オペレーション！

初期構成時に使用しなかった空き Disk スロットに Disk 追加する事によってストレージ容量のみの追加する事ができます (ノードやメモリの拡張も可能)。

また、VxRail の新ソフトウェアバージョン v4.7.300 以降では、ノード追加時のバージョン互換性チェックが強化され、必要に応じて自動で追加ノードをアップグレードしてくれるようになりました。

続いて【HCIのメリット】に関してご紹介します。

1. 運用管理者の負担軽減

1台の筐体にサーバーとストレージを搭載しているため、サーバーとストレージを接続するための機器を用意する必要がありません。HCI ならサーバーとストレージもまとめて監視できるので手間が省けますね。

省スペース・省電力も実現でき、トータルコスト (TCO) も抑えられて一石二鳥です。

2. スモールスタート

オンラインでカンタンにシステムを拡張／縮小できるので、いきなり大規模導入しなくてもスモールスタートすることができます。

次は【VxRail が選ばれる理由】についてご紹介致します！

1. VMware と Dell EMC で共同開発された唯一の HCI

VxRail は VMware との親和性が非常に高く、vSphere ユーザーは既存環境を変更することなく運用することができます。

サポートも 24 時間 365 日国内に設けたサポートセンターで日本人が受付し、ハードウェア (Dell EMC) とソフトウェア (VMware) の区別なく受付してくれるため、運用する方は非常に安心ですね。

Horizon や NSX などの VMware 製品 (※) や Dell EMC が提供するネットワークスイッチの Power Switch シリーズも VxRail サポート窓口で一括受付してくれます。VxRail と VMware それぞれのエンジニアが内部で密に連携しているので、複雑な事象でも問題解決までスムーズです！

※ Dell EMC OEMライセンスが対象です。

※ VMware 純正ライセンスの場合は VxRail 保守契約を Pro Support Plus でご契約頂ければ、Dell EMC 社での一括窓口をご提供可能となります。

2. 周辺ソリューションとの相性抜群

ストレージ領域の増設は Unity や Isilon 、バックアップは Avamar や PowerProtect DD と組み合わせることで、全てのインフラを Dell EMC で統一管理できるので、さらに管理が楽になります。

最後に【まとめ】です。

Dell EMC と VMware の共同開発製品のためメリットがたくさんありましたね。

本日は大きく下記の 2 つの事をぜひ、覚えておいてください。

1. vSphereに最適化されているため、仮想環境の運用効率性が高い

2. 稼働状況確認もサポート窓口も、ハードウェア (Dell EMC) とソフトウェア (VMware) 区別なく確認できるので、問題解決までスムーズです

【次回予告】

次回は VxRail の管理画面について紹介致します。

VxRail の vSphere 環境は vCenter のプラグインから管理することができるため、手順と共にその手軽さをご紹介させていただきます。お楽しみに！

そしてそして…！もっと VxRail について知りたい方は、VxRail チャンピオンクラブにご参加ください！

vSphere/vSANの情報から、VxRailの運用に関するTipsや最新情報を入手することができるコミュニティです。

▼株式会社ネットワールド（VxRailチャンピオンクラブ）

https://www.networld.co.jp/product/emc/emcvxrail_championsclub/

The post 今更聞けない！VxRail 基本のあれこれ appeared first on Japan Cloud Infrastructure Blog.

みなさん初めまして！

日本ヒューレット・パッカード株式会社（HPE）の橘孝祐（たちばなこうすけ）と申します。サーバー製品のプリセールスを担当しておりまして、VMware 仮想化技術支援をメインに行っております。

2020/4/2に vSphere 7が General Availability (GA) になりました。約 5 年ぶりのメジャーアップデートということで、どんな新機能が追加されたの？アーキテクチャの変更は？話題のコンテナ実装の情報は？対応機種は？などなど 知りたいことだらけではないでしょうか。今回から数回に分けて皆様の疑問を少しでも解決できるような有益な情報を展開していきますので、楽しみにしていてください。

本日はその中でも 3 点先出しでご紹介したいと思います。

■対応機種公開！

まずは HPE ProLiant/Apollo サーバーファミリーの vSphere 7 対応機種のご紹介です。

図 1. vSphere 7 対応 HPE Gen10/Gen10 Plus サーバープラットフォームポートフォリオ（ProLiant およびApolloファミリー）

図1は vSphere 7 に対応した HPE サーバーです。最新情報は下記のリンクにありますので、導入前に是非チェックいただければと思います。

https://techlibrary.hpe.com/us/en/enterprise/servers/supportmatrix/vmware.aspx

最新第二世代の AMD®EPYC^TM7000 シリーズプロセッサーを搭載した ProLiant DL325/385 Gen10 Plus サーバーももちろんサポート。ご家庭や SOHO ・オフィス向けの超小型最新サーバー 「Micro Server Gen10 Plus」も vSphere 7 をサポートしています。タワー型、ラックマウント型、高密度/HPC 型と HPE の豊富なラインアップでいち早く vSphere 7 をお使いになることができます。ポートフォリオの多さが HPE のウリです！

■GA 当日にバイナリ公開！

HPE では汎用サーバーである HPE ProLiant Server シリーズ向けの Custom ISO が GA 当日に公開されています。

図2. vSphere 7向けのベンダー Custom ISO のダウンロード（2020/4/13現在）

バイナリの入手は以下の URL からになります。（※入手にはMy VMware のアカウントが必要です）

https://my.vmware.com/en/group/vmware/info?slug=datacenter_cloud_infrastructure/vmware_vsphere/7_0#custom_iso

GA から10日が経過した 4/13 現在、Dell EMC さんと HPE が Custom ISO と Vendor Add-on を公開しています。

Custom ISO とは、VMware オリジナルのインストール ISO (Base Image）にサーバーベンダー各社が採用している NIC や HBA、RAID カードなどのデバイスドライバをあらかじめ組み込んだものです。HPE の場合、必ずしもこれを利用する必要はありませんが、Custom ISO を利用しない場合は

1. 何のドライバが入っていないのかの確認
2. 確認したドライバの入手
3. 入手したドライバを ISO に組み込み、独自の Custom ISO としてリビルド

という煩雑な手順を踏んでようやく ESXi のインストールを始めることができます。ざっくり分けて3つの手順でできますが、「○○のドライバを追加し忘れた」や「独自の Custom ISO がうまく読み込まれない」といったことでスムーズに進まないことも少なくありません。これだけでもベンダー側で動作が確認されている Custom ISO の有益さが伝わっていただけたかと思います。

そして、これまでも vSphere Update Manager (VUM) を使用してパッチ適用やアップグレードを行っていましたが、vSphere 7からは vSphere Lifecycle Manager (vLCM) という新機能を用いて vCenter からもっと効率よくパッチ適用やアップグレードができるようになります。

図 3. vSphere 7の ESXi Image 構成要素

vSphere 7 では、アップグレードの際に上記画像のように構成要素が分かれて一つの ESXi Image を構成しています。Component は論理的にグルーピングされた VIB（ソフトウェアパッケージ）、Base Image は VMware 社から提供される ESXi Image, そして Vendor Add-on は vLCM を使用するにあたってベンダー側から提供するファームウェアやドライバ類になります。Vendor Add-on を適用することで、細かなファームウェアやドライバの変更に対してvCenter Server から効率よくアップデートを行うことができます。

※vLCMについて詳細は次回以降の記事でご紹介！

■新機能公開！

最後に、皆様が気になっている新機能について、ざっと一覧でリストアップいたします。今回は数も多いので、機能名と機能概要を一言のみお伝えいたします。

表 1. vSphere 7 新機能一覧

これだけの豊富な新機能の一方で、現場の皆様の本音としては、「GA されたばかりのものなんて既存 Version からのアップグレードが失敗したらどうする」といった不安や、「いきなりインストールに失敗したら嫌だから周りが使い始めるまで様子見しよう」といった気持ちがあるかと思います。そんな皆様に向けて、HPE としてはまず【インストール】【アップデート】に焦点を当てて実機での検証をスタートしております。検証結果を元に、今後皆様が安心して vSphere 7 を HPE でいち早く使い始められるよう情報を更新していきます！

今後のブログ更新にもご期待ください！

—-

橘 孝祐（Tachibana Kousuke）

日本ヒューレット・パッカード株式会社（HPE）でHPE ProLiant Server シリーズを中心とするサーバー製品を担当。主に VMware 仮想化ソリューションと組み合わせたプリセールス活動に従事。

The post VMware vSphere 7待ちに待った メジャーアップデート速報！【HPE】 appeared first on Japan Cloud Infrastructure Blog.

皆様こんにちは！株式会社ネットワールドの Dell EMC 製品担当です。

本日は第 2 回、Dell EMC VxRail の管理画面と vCenter プラグインについてご紹介させていただきます！

第 1 回目の記事をご覧になりたい方はこちらになります。

1. VxRail 管理画面に関して

VxRail の vSphere 環境は vCenter のプラグインから簡単に管理することができますよ！

どれだけ簡単に管理できるのか？具体的にどのようなオペレーションになるのか？実際の管理画面を見ながら確認していきましょう。

まずは「メニュー」から「VxRail」を選択すると VxRail ダッシュボードを見ることができます。もちろん日本語化されています。

ここでは以下の情報を見ることができます。

・システムの稼働状態：

VxRail クラスタ全体のステータスの確認

・VxRail コミュニティ：

Dell EMC のサポートサイトの最新の VxRail のトピックが一覧で表示

・サポート：

サポートとチャット、サービスリクエストを作成、ダウンロードが利用可能

・ナレッジベース：

Dell EMC のナレッジベースにアクセスできる

クラスタ及び各ホストを右クリックすると、いつものメニューの中に「VxRail」というメニューが追加されています。

クラスタの場合はホストの追加とクラスタのシャットダウン、ホストの場合はクラスタからのホストの削除とホストのシャットダウンができます。

クラスタ→「監視」→「VxRail」→「アプライアンス」からクラスタを構成するホストの情報やステータスをまとめて確認できます。各ホストの筐体の画像を選択するとホストの詳細な情報の確認ができます。

また「アクション」からは、「ホストの情報の表示」、「システムの LED の有効」、「ホストのシャットダウン」、「ディスクの追加」、「クラスタからのホストの削除」などのオペレーションができます。

ちなみにディスクの追加を選択するとこのようなウインドウからディスクを追加することが出来ます。

各ホスト→「監視」→「VxRail」→「物理ビュー」からはホストのコンポーネントごとのステータスと情報を確認することができます。

これなら障害が起きた時、どのコンポーネントが原因となっているのかをグラフィカルに確認することができますね！

また各ホスト→「設定」→「VxRail」→「iDRAC構成」から iDRAC の情報まで vCenter から確認することができます。

クラスタ→「設定」→「VxRail」→「システム」からクラスタのバージョンを確認できます。今回のVxRailがバージョンが4.7.301であることが分かりましたね！

クラスタ→「設定」→「VxRail」→「更新」からは VxRail のシステムのアップデートができます。

インターネットアップデートのタブでは、現在の最新のバージョンが分かります。先ほど今回のシステムのバージョンが 4.7.301 だと確認出来ましたので、4.7.410 にバージョンアップすることができます。またローカルアップデートでは、ローカルに保存したイメージから任意のバージョンへのアップデートができます。

バージョンアップデートは Dell EMC のサポート (ProSupport MC/ProSupport Plus) をご契約頂ければ、VxRail 専任サポートエンジニアがリモートにてバージョンアップ作業を保守範疇内 (無償) で実施させて頂く事が可能です。

しかも VxRail の場合、アップデートバイナリに含まれている VMware 側のコンポーネント（vSphere や内部 vCenter など）も保守範囲内でアップデートが可能となっており、ハードウェア側のファームウェアバージョンとのコンパチも Dell EMC にて検証済みのため安心です。

また新しいバージョンがリリースされるのもとても速く、今話題の vSphere7 についても VxRail ではすでに対応済みでとなっています！

2. リモート保守に関して

せっかくなので Dell EMC のリモート保守についても少しご紹介したいと思います。

リモート保守は大きく 2 つに分けられます。

SRS (Secure Remote Service) はお客様の運用をアシストする Dell EMC オリジナルのツールです。

ご採用頂くと Dell EMC 製品 (VxRail ももちろん対象です) の管理をする事が可能で、ログデータなどを Dell EMC 社へ一定間隔でセキュアな HTTPS で送信する事ができます。ハードウェアの障害などの場合は Dell EMC 社側で自動受付が行われ、送信されたログからの切り分け及び対処方法を確立した上でお客様へご連絡をするなどの対応が可能となっています。

さらにリモート接続ツール (Zoom 等) をご利用いただければ、VxRail 専任サポートエンジニアが直接リモートでアップデートやログの採取をしてくれ、よりスピーディにトラブルシューティングをしてくれます。

基本的には SRS とリモート接続ツールの両方利用を推奨していますが、セキュリティの厳しい環境のお客様では外部への接続はポリシー上、制限されている場合も多々ありますよね。

そんな方でも安心してください！VxRail はログ採取も簡単なんです！！

通常は VMware 側とハードウェア側で両方のログ採取をして欲しいとよく言われますよね。

VxRail Manager はその両方に対応しており、先程ご紹介した通り vCenter のプラグインとして組み込まれているので、vCenter からストレージもサーバー (iDRAC) も vCenter/vSphere のところも全て一括で採取できます。

しかもコマンド不要！全て GUI でポチポチっと 4 ステップで取得できます。

通常、自身で障害対応をするのは本当に大変ですよね。

「ログを確認しろって…エラーの検出キーワードは何？そもそもどこがエラーなの！？」

「ログの採取方法ってどうするんだっけ？コマンド分からないよ～！！」

「何度も何度も電話とメールでやりとりしないと進まない！！」

「え！？ ハードウェア側のログも欲しいって？取り方はハードウェアベンダーに問い合わせするの？？」

なんてご心配はもう要りません！

VxRail のリモートサポートをうまく利用し、障害時の対応を最低限に抑えながら確実な運用を目指しましょう！！

【まとめ】

クラスタ、ホスト、構成コンポーネントの単位でステータスが一目で確認することが出来ました。またホストの追加やディスクの追加などのオペレーションも vCenter から行えることがわかりました。

1 クリックでオペレーションができるように設計されていることや、グラフィカルな表示などは、直感的で初心者にとても優しい管理画面でしたね！

VxRail 管理画面の vCenter プラグインは VxRail 4.7.110 以降で実装されていますが、4.7.300 以降ではさらに vCenter への統合が進んでいます。進化し続ける VxRail は目が離せませんね！

【次回予告】

次回は All NVMe に対応した VxRail をご紹介したいと思います。お楽しみに！！

そしてそして…！もっと VxRail について知りたい方は、VxRail チャンピオンクラブにご参加ください！

vSphere/VMware vSAN の情報から、VxRail の運用に関する Tips や最新情報を入手することができるコミュニティです。

▼株式会社ネットワールド（VxRailチャンピオンクラブ）

https://www.networld.co.jp/product/emc/emcvxrail_championsclub/

The post VxRail vCenter プラグインをさわってみました！ appeared first on Japan Cloud Infrastructure Blog.

皆様こんにちは！株式会社ネットワールドの Dell EMC 製品担当です。

連載 3 回目は「All NVMe に対応した VxRail」についてご紹介したいと思います。

さて、みなさん、NVMe ってもうご存知ですよね？
まだ不安な方はこちらをご確認ください。

今まで VxRail はキャッシュだけ NVMe でしたが、約半年前にリリースされた VxRail4.7.4xx から All NVMe に対応した新機種が 2 つ発表されています。今日は改めて All NVMe 対応のハードウェア「E560N/P580N」をご紹介致します。

E560N

Dual-Soket、All NVMe の 1U アプライアンス

※E560 が All NVMe に対応したとイメージしてください。

E560N はまさに省スペースでハイスペックとなるので様々な用途がありそうですし、兄弟機の E560 はまさにネットワールドでも不動の一番人気のモデルです。

P580N

Quad-Soket、All NVMe の 2U アプライアンス

P580N は Quad も何に使うの？という疑問を持たれた方もいるかと思います。

実はこの超ハイスペックの利用用途はずばり、「SAP HANA」での利用を想定しています。
すでに SAP HANA の HCI として運用できる事がいち早く認定されています。

https://www.sap.com/dmc/exp/2014-09-02-hana-hardware/enEN/hci.html#recordid=2173

これにより HCI のメリットを享受する形で SAP HANA を HCI 基盤で安心・安全に稼働させることが可能になります。

P580N に関しては Quad 対応ということで今までの VxRail になかった全く新しいハードウェアになりますので、ハードウェア構成に関してもご説明させて頂きます。

搭載可能な CPU はハイエンドモデルということもあり、Intel Xeon 型番 :  52XX～82XX を構成可能で 35 種類 (2020 年 6 月現在) とハイエンドモデルでありながら柔軟な選択が可能です。

E560N に関しては E560 の筺体を採用し、対応ドライブが SAS から NVMe に変更されている点以外は大きな変更点はありませんので、Intel Xeon 型番 :  32XX～82XX までさらに幅広い選択が可能で 54 種類 (2020 年 6 月現在) とさらに構成パターンが増えています。

VxRail は比較的ハードウェア構成が制限されがちな HCI アプライアンスでありながら、ハードウェアの選択が非常に多いというメリットがありますが、新機種になってもそのコンセプトは継続しているという事になります。また、非常に選択肢が多いハードウェア構成とソフトうウェアを一元的にサポートできるという事も管理者の皆様には非常に安心ではないでしょうか。

そして気になる NVMe SSD ですが、E560N と P580N で同じ容量のドライブを提供致します。

最大で 4TB を提供しますので E560N は 1 ノードあたり 32TB (4TB×8) 、P580N は 1 ノードあたり80TB (4TB×20) が最大容量となります。

続いてキャッシュについては以下の通りとなります。

All NVMe モデルなのでキャッシュも当然 NVMe なのですが、もう一つ “Optane” のオプションが選択出来ます。

Intel Optane は実はキャッシュ用として従来の VxRail でもサポートしていましたので新規対応ということではございませんが、あまり聞いたことがないという方が多いのではないでしょうか？

Intel Optane は、Intel 社と Micron 社が共同開発した「3D Xpoint」を採用した SSD であり、従来の NAND フラッシュと比べて耐久性と性能に優れている製品となりまし、VxRail が採用している VMware vSAN でも非常にパフォーマンスが発揮されることが期待されます。

今回サポートされているキャッシュ用ドライブのスペックで比較してみましょう。

レイテンシは 3 倍、書込耐久性を表す DWPD (Drive Writes Per Day) は 12 倍と圧倒的な差が出ています。

キャッシュ用ドライブはアクセス頻度が高いので当然性能面、耐久性が高いというのが求められますが、まさに Intel Optane は VxRail にうってつけと言えるでしょう。

とここまではスペック上でのお話をしてまいりましたが、やはり気になってくることがありますよね。そうです、実際に VxRail で Intel Optane を搭載したらいったいどれくらいの性能が出るのでしょう！と。

オールフラッシュモデルであり、不動の一番人気モデルであるEシリーズの E560F に Optane をキャッシュとして搭載したらどれくらいの性能が出るのか？とか考えていたらいつのまにか実機を用意していました。。。。

【開梱の儀】

【Optane 外観】

次回 Part4 では Intel Optane をキャッシュドライブで利用するとどれくらい性能が出るのか？をネットワールドが誇る優秀な SE が検証した結果を大公開します。

なお、VxRail の詳細を知りたいと思われた方は、「EVOLVE ONLINE」にご登録・ログインいただくことで、説明動画および資料がダウンロードできます。是非、アクセスしていただけますと幸いです。

EVOLVE ONLINE ご登録 >> マイページ >>「ウェビナーを視聴する」メニュー

また、「EVOLVE ONLINE」では様々なコンテンツを提供しております。お客様の抱えられている課題に対する解決策がきっと見つかると思います。

ぜひ次回の更新をお楽しみに！

The post All NVMeに対応したVxRail appeared first on Japan Cloud Infrastructure Blog.

Part3：ユーザーインターフェースの変更いろいろ

日本ヒューレット・パッカード株式会社の中川明美です。
今回は、Part3の「ユーザーインターフェースの変更いろいろ」です。
vRealize Operations7.5から、カスタムダッシュボードの作成方法がアップデートされています。ウィジェット間の関係を指定する方法が容易になりました。ドラッグ操作で視覚的に設定できます。
このPartでは、復活した「ワークロード」タブ、メトリックを使用したカスタムダッシュボードの作成を例に進めます。

-Back Number-

#1：vROps バージョン 8.0 でできること①
#2：vROps バージョン 8.0 でできること②
#3：ユーザーインターフェースの変更いろいろ
#4：スーパーメトリックもウィザードを強化
#5：アプリケーションの管理①
#6：アプリケーションの管理②
#7：Workbench によるトラブルシューティング
#8：vROps 8.0 の vSAN ダッシュボード/ SDDC コンプライアンス

◆ワークロード◆

「ワークロード」タブが復活しました！！！
「CPU」と「メモリ」の構成サイズ(キャパシティ)が妥当であるかを分析する最初のステップとして使用していたため、うれしい限りです！
メモリのワークロードの内訳の数値は、「消費」から「デマンド」へ変更されています。

上図は「クラスタ」オブジェクトを選択したワークロード画面です。
クラスタのデマンドは80%を超え、赤色の警告表示になっています。しかしすべての仮想マシンのデマンドが高い値を示しているわけではありません。仮想マシンのメモリ構成サイズが適正サイズより大きい場合、このような結果になることがあります。エンドユーザー様の環境でもよく見かけるメモリ状況です。
仮想マシンのメモリサイズを最適な値に変更すれば、クラスタのデマンド値や使用量を下げることができます。

低パフォーマンスの仮想マシンの誤ったチューニング例をご紹介します。
クラスタやホストのメモリ使用量から、低パフォーマンスの原因をメモリと判断し、「ホストのメモリ増設」＆「仮想マシンのメモリ割り当て追加」があげられます。しかし、仮想マシンやゲストOSまで視点を広げると、仮想マシンのメモリサイズは十分であり、CPU数が原因だったということもあります。
今回の例のように、クラスタのデマンドは高い状態であっても、デマンドが高くない仮想マシンが存在する場合は、それらの仮想マシンを最適なメモリサイズへ変更することを検討ください。
仮想マシンを最適なメモリサイズに変更してホストのメモリ使用量が下がれば、パフォーマンスに影響を与えることなく、メモリリソースの最適化が可能です。

ここからは、1つの仮想マシンをフォーカスし、詳細に分析してみます。下図(赤色点線枠)から、「キャパシティ(メモリ構成サイズ)」「デマンド」「使用量」を比較します。この仮想マシンは「4GB」でメモリを構成しています。デマンド値は「3.49GB」です。過去6週間の平均使用量は「774.68MB」です。
仮想マシンはデフォルトでは実際の物理メモリ使用量に関わらず、構成(最大)サイズまで要求することが可能です。仮想マシンのデマンドに応じて、物理メモリが割り当てられるため、クラスタ(またはホスト)の使用率が高くなる傾向があります。

次に、「ゲスト使用量」「ゲストデマンド」「mem.standby.normal_latest」のメトリックを使用して、仮想マシンのメモリサイズが適正であるかを比較検討してみます。ゲストOSは、一般的なOSとアプリケーションの関係とは異なり、割り当てられた物理メモリを解放せず、最近使用していないメモリをフリーリストに移動します。物理メモリ不足時には、バルーニングによって、GuestOS未使用のメモリは再利用されます。
仮想マシンの「ワークロードのメモリ使用量」と「ゲスト使用量」の値は次の通りです。収集期間や計算方法は異なりますが、仮想マシンのワークロードのメモリ使用量 (約775MB) と、ゲスト使用量(最高値と最低値の平均値 は約754MB) は近い値です。仮想マシンが使用している物理メモリが、ゲストOSに割り当てられていることがわかります。

・仮想マシンのワークロードのメモリ使用量：774.68MB　※過去6週間の平均値
・ゲスト使用量： 809, 052.81KB (約790MB)　※過去7日間の最高値

「ゲスト使用量」と「ゲストデマンド(要求値)」を比較すると、ゲストデマンドはゲスト使用量の半分未満です。これらの値から、ゲストOSは割り当てられた物理メモリの半分も要求していないことがわかります。

・ゲストデマンド：322,784KB (約315MB)　※過去7日間の最高値

mem.standby.normal_latestの値を確認します。「ゲスト使用量」の半分近くあります。この値から、割り当てられた物理メモリの半分ほどが最近未使用であることがわかります。

・standby.normal_latest：415,732.28 (約406MB)　※過去7日間の最高値

これらの状況から、4GBのメモリの構成サイズを減らせるのではないかと検討できます。
継続的な監視を前提に、仮想マシンやゲストOSのメトリックから判断すると、たとえば1GBまで減らせるのではないでしょうか。仮想マシンの構成サイズを4GBから1GBへ変更すると、仮想マシンのデマンド(3.49GB)も減りますから、ホストの使用量を抑えられそうですね。

話は変わりますが、メトリックの画面上部にオブジェクトの関係性が表示されるようになりました。
また、以前は最近未使用のフリーリストの値を監視するために、「空きメモリ(上図の赤点線枠)」を使用していましたが、vRealize Application Remote Collectorによって収集される「standby.normal_latest」の方がより正確な値が得られそうですから、こちらを使用しました。

◆カスタムダッシュボード◆

「ダッシュボードの作成」では、最初にダッシュボードを構成するパーツをドラッグします。
画面右下から「ウィジェット」または「ビュー」に切り替え、パーツを追加することができます。

ここから、適正サイズを分析するためのダッシュボードを作成してみようと思います。
「オブジェクトリスト」で選択した仮想マシンの「メモリ」と「CPU」のメトリックを表示します。

ダッシュボード作成時には、メトリックの単位を変更することができます。
メモリは「KB」から「GB」へ、CPUは「KHz」から「GHz」へ変更しました。残念ながら、「standby.normal_latest」メトリックは変更することができませんでした。

▼相互作用

相互作用は、矢が付いているアイコンから、連携したいウィジェットにドラッグします。この設定により、リストで選択したオブジェクトに関するメトリックが表示されます。
できない操作は、ドラッグ後の線が表示されませんから、設定ミスを防ぐこともできます。オブジェクトリストの矢が付いていないアイコンからドラッグしても、線は表示されません。

▼「仮想マシンキャパシティ」の確認

「仮想マシンリスト」で選択した仮想マシンの「CPU」および「メモリ」のメトリックが表示されるカスタムダッシュボードが作成できました。

適正な構成サイズ(キャパシティ)は、デマンド値を参考に比較検討します。

【メモリ】
表示された期間の使用量のMAX値は約2.5GB、デマンドは0.5GB程度です。使用量よりデマンド値は低く、フリーリストにもメモリがある状況です。デマンド値を参考に1GBまで減らしたとしてもゲストOSの要求は十分に満たせそうです。構成サイズを減らす変更が心配なら、仮想マシンの設定の編集で「制限」を利用し、しばらく監視するのもよいかもしれません。
「構成サイズ」より「デマンド」が高い場合はメモリの追加を検討します。「デマンド」より「使用量」が低い場合は競合の発生を疑います。

【CPU】
CPUはデマンドおよび使用量も、物理コアの性能(2.2GHz)を上回っていませんから、現在の1vCPUで問題なさそうです。「デマンド」が性能を上回る場合は、vCPUの追加を検討します。

◆まとめ◆

vROpsは、Advanced以上のライセンスがあればダッシュボードのカスタマイズできますから必要な情報を限定して表示することができますね。また、vRealize Application Remote Collectorで収集されるゲストOSのメトリックを使用すれば、仮想マシンとゲストOSのデータを比較することも可能です。より確かな分析ができますね。
カスタム作成は以前のバージョンと比べ容易になってきましたから、ご自身の環境に合わせ準備頂けると、vROpsをより活用できると思います。
次回はスーパーメトリックの作成方法をご紹介します。スーパーメトリックの作成も簡単になりましたよ。

The post vROps 8.0 はオンプレミスからクラウドまで Part3 appeared first on Japan Cloud Infrastructure Blog.

皆様こんにちは！株式会社ネットワールドの Dell EMC 製品担当です。

連載 3 回目は「All NVMe に対応した VxRail」についてご紹介したいと思います。

さて、みなさん、NVMe ってもうご存知ですよね？
まだ不安な方はこちらをご確認ください。

今まで VxRail はキャッシュだけ NVMe でしたが、約半年前にリリースされた VxRail4.7.4xx から All NVMe に対応した新機種が 2 つ発表されています。今日は改めて All NVMe 対応のハードウェア「E560N/P580N」をご紹介致します。

E560N

Dual-Soket、All NVMe の 1U アプライアンス

※E560 が All NVMe に対応したとイメージしてください。

E560N はまさに省スペースでハイスペックとなるので様々な用途がありそうですし、兄弟機の E560 はまさにネットワールドでも不動の一番人気のモデルです。

P580N

Quad-Soket、All NVMe の 2U アプライアンス

P580N は Quad も何に使うの？という疑問を持たれた方もいるかと思います。

実はこの超ハイスペックの利用用途はずばり、「SAP HANA」での利用を想定しています。
すでに SAP HANA の HCI として運用できる事がいち早く認定されています。

https://www.sap.com/dmc/exp/2014-09-02-hana-hardware/enEN/hci.html#recordid=2173

これにより HCI のメリットを享受する形で SAP HANA を HCI 基盤で安心・安全に稼働させることが可能になります。

P580N に関しては Quad 対応ということで今までの VxRail になかった全く新しいハードウェアになりますので、ハードウェア構成に関してもご説明させて頂きます。

搭載可能な CPU はハイエンドモデルということもあり、Intel Xeon 型番 :  52XX～82XX を構成可能で 35 種類 (2020 年 6 月現在) とハイエンドモデルでありながら柔軟な選択が可能です。

E560N に関しては E560 の筺体を採用し、対応ドライブが SAS から NVMe に変更されている点以外は大きな変更点はありませんので、Intel Xeon 型番 :  32XX～82XX までさらに幅広い選択が可能で 54 種類 (2020 年 6 月現在) とさらに構成パターンが増えています。

VxRail は比較的ハードウェア構成が制限されがちな HCI アプライアンスでありながら、ハードウェアの選択が非常に多いというメリットがありますが、新機種になってもそのコンセプトは継続しているという事になります。また、非常に選択肢が多いハードウェア構成とソフトうウェアを一元的にサポートできるという事も管理者の皆様には非常に安心ではないでしょうか。

そして気になる NVMe SSD ですが、E560N と P580N で同じ容量のドライブを提供致します。

最大で 4TB を提供しますので E560N は 1 ノードあたり 32TB (4TB×8) 、P580N は 1 ノードあたり80TB (4TB×20) が最大容量となります。

続いてキャッシュについては以下の通りとなります。

All NVMe モデルなのでキャッシュも当然 NVMe なのですが、もう一つ “Optane” のオプションが選択出来ます。

Intel Optane は実はキャッシュ用として従来の VxRail でもサポートしていましたので新規対応ということではございませんが、あまり聞いたことがないという方が多いのではないでしょうか？

Intel Optane は、Intel 社と Micron 社が共同開発した「3D Xpoint」を採用した SSD であり、従来の NAND フラッシュと比べて耐久性と性能に優れている製品となりまし、VxRail が採用している VMware vSAN でも非常にパフォーマンスが発揮されることが期待されます。

今回サポートされているキャッシュ用ドライブのスペックで比較してみましょう。

レイテンシは 3 倍、書込耐久性を表す DWPD (Drive Writes Per Day) は 12 倍と圧倒的な差が出ています。

キャッシュ用ドライブはアクセス頻度が高いので当然性能面、耐久性が高いというのが求められますが、まさに Intel Optane は VxRail にうってつけと言えるでしょう。

とここまではスペック上でのお話をしてまいりましたが、やはり気になってくることがありますよね。そうです、実際に VxRail で Intel Optane を搭載したらいったいどれくらいの性能が出るのでしょう！と。

オールフラッシュモデルであり、不動の一番人気モデルであるEシリーズの E560F に Optane をキャッシュとして搭載したらどれくらいの性能が出るのか？とか考えていたらいつのまにか実機を用意していました。。。。

【開梱の儀】

【Optane 外観】

次回 Part4 では Intel Optane をキャッシュドライブで利用するとどれくらい性能が出るのか？をネットワールドが誇る優秀な SE が検証した結果を大公開します。

なお、VxRail の詳細を知りたいと思われた方は、「EVOLVE ONLINE」にご登録・ログインいただくことで、説明動画および資料がダウンロードできます。是非、アクセスしていただけますと幸いです。

EVOLVE ONLINE ご登録 >> マイページ >>「ウェビナーを視聴する」メニュー

また、「EVOLVE ONLINE」では様々なコンテンツを提供しております。お客様の抱えられている課題に対する解決策がきっと見つかると思います。

ぜひ次回の更新をお楽しみに！

The post All NVMeに対応したVxRail appeared first on Japan Cloud Infrastructure Blog.

みなさんこんにちは！

日本ヒューレット・パッカード株式会社（HPE）の橘孝祐（たちばなこうすけ）です。

前回は速報として VMware vSphere 7.0の HPE サーバーの対応状況や Custom ISO の公開、新機能一覧などをご紹介しました。今回は vSphere 構成を組むうえでのハードウェア要件として意外な注意ポイントである「ブートデバイス」についてご紹介いたします。

Backnumber

第1回　VMware vSphere 7待ちに待った メジャーアップデート速報！【HPE】

第2回　vSphere 7.0 時代のESXiブートデバイスの選び方【HPE】

第3回　vSAN はファームウェアとドライバのチェックを忘れずに！！【HPE】

■そもそも vSphere の構成を組むうえでチェックすることは？

vSphere の構成を組む際の最小ハードウェア要件は下記になります。

https://docs.vmware.com/jp/VMware-vSphere/7.0/com.vmware.esxi.install.doc/GUID-DEB8086A-306B-4239-BF76-E354679202FC.html

以上の内容をまとめると、

• 2 コア以上のCPU
• 8 GB以上のメモリ
• ブートデバイスとして、USB/SD デバイス用に 8 GB以上、HDD/SSD/NVMe などのデバイスタイプ用に 32 GB以上

となります。CPU とメモリに関しては、一般的に仮想マシンを動かすために用意するハードウェアで気にすることはほとんどなく、vSphere のハードウェア要件は非常にハードルが低いです。

一方で、ブートデバイスに関してはスタンダードな HDD/SSD での RAID 構成であれば特に最小要件を意識しないかもしれませんが、ESXi のブート領域専用であれば価格の安い USB ドライブや SD カードをブートデバイスとして選定されている方も多いかと思われます。

■USB/SD フラッシュデバイスにおける推奨は 32 GB

USB ドライブや SD カードといったフラッシュデバイスをブートデバイスとして利用する場合の最小ハードウェア要件は 8 GB 以上ですが、VMware としては 32 GB以上を推奨しており、HPE としても 8 GB のフラッシュメディア製品が販売終了予定となっています。

図1. ESXi のフラッシュメディアブート製品

フラッシュメディアにおいて 32 GB 以上を推奨する理由としては以下の2つがあります。

1. ROM データ領域としての ESX-OS Data 領域を十分に確保するため
2. 将来的な追加モジュールに備えて Boot bank 領域を確保するため
3. ブートデバイス自体の書き込み容量に余裕を持たせ、デバイス単体の寿命を延ばすため

聞きなれない言葉もあるかと思いますので、順を追って説明していきます。

まず、ESXi 7.0 ではシステムストレージレイアウトが図2のように変わっています。コアダンプやスクラッチと個別に分かれていたパーティションから、ESX-OS Data 領域として統合的に確保され、この中でコアダンプやスクラッチ機能の読み書き領域として使用されます。USB ドライブや SD カードの場合は ESX-OS Data 領域が ROM データ専用となり、RAM データはメモリ（DIMM）上に構成されます。図3 のように system boot 領域や Boot bank 領域を除いた残りのデータ領域が ESX-OS Data 領域として割り振られており、ROM データ領域として十分に確保するには 32 GB 以上が推奨となります。

図2. ESXi 7.0 のシステムストレージレイアウト (VMware vSphere blogより)

https://blogs.vmware.com/vsphere/2020/05/vsphere-7-esxi-system-storage-changes.html

また、メディアサイズによって Boot bank 領域が 500MB, 1GB, 4GB と可変になります（図3）。Boot bank 領域が最大の 4GB となるのが 32GB 以上のメディアサイズとなるため、今はまだ予定がなくとも今後の機能拡張に備えて Boot bank 領域の容量を十分に確保しておくことが推奨されます。

特に、NSX-T や NVIDIA GPU を利用する場合は、ドライバ関連のフットプリントが大きいために Boot bank 領域の容量が枯渇してしまうといったトラブルが私の知るお客様でもいくつか見られています。vSphere 7.0 では Boot bank 領域の容量は増えておりますが、USB/SD フラッシュデバイスを利用する場合は注意が必要です。

【参考】https://docs.vmware.com/jp/VMware-NSX-T-Data-Center/2.5/installation/GUID-8490FFB5-7B76-4EDC-B1A3-6CC4E63C5098.html

図3. ESXi 7.0 でのメディアサイズとパーティションの関係 (VMware vSphere blog より)

https://blogs.vmware.com/vsphere/2020/05/vsphere-7-esxi-system-storage-changes.html

さらに、USB ドライブや SD カードはフラッシュデバイスのため、SSD と同様に書き込み回数や保持期間がある程度定まっています。書き込み領域に余裕のない状態が続くと、同じフラッシュ領域に対する書き込みの割合が増し、結果としてフラッシュデバイスの寿命を早めることになります。

以上の3つを踏まえて、ESXi のブートデバイスとしてフラッシュメモリを利用する場合は 32GB 以上を選択することを推奨いたします。

■本命はノート PC でも利用されるM.2 SSD

USB ドライブや SD カードは価格が安い反面、ログを保存する領域であるスクラッチ領域がメモリ（DIMM）上に作成されます。メモリは揮発性のため、電源障害などで電力供給がストップした場合や再起動がかかってしまうとスクラッチ領域が消えてしまい、スクラッチログからのトラブルの原因調査ができなくなります。

かといって、通常の HDD や SSD を選択すると、サーバーのディスクベイを消費してしまううえ、ブートデバイスを冗長化（ミラーリング）すると、vSAN の場合にはディスクコントローラー（RAIDコントローラー）をブート用と vSAN データストア用とで 2 枚用意せねばならず、コストやスペース的な課題もありました。

こちらの課題に対する“本命”としては、ノート PC で使われる 「M.2 SSD」 と言われています。図4 のような、板ガムのようなメモリのような小型の SSD です。これにより USB/SD のスクラッチ領域の問題も回避しながら、サーバーのディスクベイをブート用に余計に消費する HDD/SSD ハードウェアRAIDを組むことなく、空いたディスクベイの分をさらなるディスクの拡張スロットとして使用することが可能になります。

USB/SD, HDD/SSD 両者のデメリットをうまく吸収し、かつ価格も比較的安価にすませることができる M.2 SSD ブートデバイス。気になる冗長化（ミラーリング）についても、数か月後の 2020 年秋ごろには HPE ProLiant サーバー用の RAID キットもリリースいたします。

図4．M.2 SSD デバイス

今回は vSphere 7.0 構成を組むうえで重要なハードウェア要件であるブートデバイスについてご紹介しました。

次回は、vSAN 7.0 対応の HPE ハードウェアに関してご紹介する予定です。次回のブログ更新をお楽しみに！

—-

橘 孝祐（Tachibana Kousuke）

日本ヒューレット・パッカード株式会社（HPE）で HPE ProLiant Server シリーズを中心とするサーバー製品を担当。主に VMware 仮想化ソリューションと組み合わせたプリセールス活動に従事。

The post 第 2 回 かゆいところに手が届く、vSphere 7/vSAN 7最新情報！【HPE】 appeared first on Japan Cloud Infrastructure Blog.

みなさんこんにちは！

日本ヒューレット・パッカード株式会社（HPE）の橘孝祐（たちばなこうすけ）です。

前回は vSphere 構成を組むうえでのハードウェア要件として意外な注意ポイントである「ブートデバイス」についてご紹介しました。

今回は vSAN 7.0 の HPE サーバー対応状況と認定構成である vSAN ReadyNode 構成の紹介、そしてファームウェアやドライバのチェック方法についてご紹介いたします。

Backnumber

第1回　VMware vSphere 7待ちに待った メジャーアップデート速報！【HPE】

第2回　vSphere 7.0 時代のESXiブートデバイスの選び方【HPE】

第3回　vSAN はファームウェアとドライバのチェックを忘れずに！！【HPE】

■ vSAN 7.0 対応 HPE ハードウェア

vSAN には、VMware 社から認証されている vSAN ReadyNode 構成と、認証 Component を組み合わせる Build Your Own 構成があります。

ここでは、vSAN ReadyNode 構成をメインにご紹介します。HPE では、vSAN 7.0 に対応した多数の vSAN ReadyNode 構成を展開しており、7/6時点で171件もの構成が認定されています。

対応サーバーの種類としては、汎用的なラックマウントサーバーで Intel 製 CPU 搭載の HPE ProLiant DL360 / 380 Gen10 を始め、高集約型の HPE Apollo シリーズ、AMD 製 CPU 搭載の HPE ProLiant DL325 Gen10/Gen10 Plus や DL385 Gen10/Gen10 Plus にも数多くの構成が認定されています。

どのような構成が vSAN ReadyNode 認定されているかは、以下の手順で確認することができます。

1. 1. HCL サイトにアクセスhttps://www.vmware.com/resources/compatibility/search.php?deviceCategory=vsan
   2. “リリースタイプ” から ESXi 7.0 (vSAN 7.0)、 “ベンダー”に Hewlett Packard Enterprise を選択して検索
   3. vSAN 7.0 対応の HPE vSAN ReadyNode 構成がリストで出力されるため、要求スペックに合わせたモデルを選択

図1. vSAN ReadyNodeのHCLサイト

また、vSAN ReadyNode 構成はルールに従ってカスタマイズすることが可能です。

必ずしも希望スペック要件が vSAN ReadyNode 構成にぴったり当てはまるとは限りらないため、下記 vSAN ReadyNode 構成のカスタマイズルールに従ってコンポーネントを変更することで、よりお客様環境にマッチした vSAN 環境を提供することが可能です。

vSAN ReadyNode 構成カスタマイズ ルール（VMware KB）

https://kb.vmware.com/s/article/52084?lang=ja

図2. vSAN ReadyNode のカスタマイズルール

図2は URL 先の VMware KB をまとめたものになりますが、アレイコントローラー以外は基本的に変更可能となります。ただし、変更可能なコンポーネントにも注意点があり、より上位のモデルにすることが必要となります。

例：HPE 1.6TB 12G SAS MU SFF SC DS SSD　→　HPE 1.6TB 12G SAS WI SFF SC DS SSD

上の例では MU → WI とパフォーマンスクラスが上がっているため変更が可能になります。

■ vSAN ReadyNode のチェックポイント  ーコンポーネントのファームウェアー

vSAN ReadyNode ではアレイコントローラーとディスク（HDD・SSD・NVMe）に関して適切なファームウェアを使用する必要があります。今回は、各コンポーネントの適切なファームウェアの検索方法をご紹介いたします。

ファームウェア確認が必要なコンポーネントに関しては、先ほどの vSAN ReadyNode と類似した個別の HCL サイトから検索することができます。

1. 1. vSAN 認証コンポーネントの HCL サイトにアクセスhttps://www.vmware.com/resources/compatibility/search.php?deviceCategory=vsan
   2. “検索対象”、 “バージョンタイプ”、 “ベンダー”等を指定して検索
   3. “検索結果”をクリックし、ファームウェア要件を確認

図3. vSAN 認定コンポーネントの HCL サイトキャプチャ①

図4. vSAN 認定コンポーネントの HCL サイトキャプチャ②

キーワードに “モデル名”や “型番”を入れて検索することも可能です。ディスクの場合はファームウェアの最小要件が書かれており、これより新しいファームウェアであれば OK となります。

例：最小要件 → HPD1 , 現在のファームウェア → HPD4 はOK

図5. vSAN 認定コンポーネントの HCL サイトキャプチャ③

アレイコントローラーの場合はファームウェアバージョンが決まっている点に注意します。ファームウェアだけでなく、対象となるデバイスドライバも確認することが重要です。

今回は vSAN 7.0 対応 vSAN ReadyNode 構成、そしてファームウェアの確認方法についてご紹介しました。

次回は、今回の続きとして HDD / SSD やアレイコントローラーといったコンポーネントのファームウェアをHPEサーバーに適用する方法、そして新機能である vSphere Lifecycle Manager (vLCM) についてご紹介する予定です。

次回のブログ更新をお楽しみに！

—-

橘 孝祐（Tachibana Kousuke）

日本ヒューレット・パッカード株式会社（HPE）でHPE ProLiant Server シリーズを中心とするサーバー製品を担当。主に VMware 仮想化ソリューションと組み合わせたプリセールス活動に従事。

The post 第 3 回 かゆいところに手が届く、vSphere 7/vSAN 7最新情報！【HPE】 appeared first on Japan Cloud Infrastructure Blog.

Virtual Cloud Network Day Live 2020 開催成功を終えての振り返り、
及びそこから見えてきた新たなネットワークのトレンドについて

VMware が New Normal 時代における新たなスタイルでイベントを実施

クラウド時代のネットワークをハードウェアではなくソフトウェアにより再定義しようとしているVMware が5月29日に新たなクラウド時代のネットワークに特化したイベントを行いました。その名も“Virtual Cloud Network Day Live 2020”。本来、東名阪と九州の会場にてライブ開催を行うプランではありましたが、時節柄 Zoom を利用したオンラインでの開催となり、運営側も様々なトライ・アンド・エラーを経ながらの準備だったため一部不手際もありご迷惑をおかけしましたが、お陰様で1,000名を超える多数のお客様にご来場（？）いただき大盛況のうちにイベントを終了させていただくことができました。ご視聴頂いた皆さま、ありがとうございました。

本イベントでは Zoom 開催ならではの醍醐味として、2つの新しい試みを試させていただきました。ひとつはセッション中にスピーカーからの1方向なご紹介だけではなく、視聴者さまが気になった点をチャット越しにライブで QA 受付させていただくというもの、もう一つはスピーカーがセッション中に簡単なアンケートを実施して皆さまのコンディションを教えていただくこと、という試みです。当初、どのくらいの QA が来るものだろうか？と運営側一同不安を持ってみていたのですが、結果として多数のご質問（総ご質問数108！）をいただき、回答準備でスタンバイしていた SE陣は大わらわ、またアンケートにも多くの視聴者から回答いただけ興味深いフィードバックとなりましたので、せっかくなのでここにそのサマリと、昨今のネットワーク事情についての考察をここでご紹介できればと思います。

セッション＃1：Virtual Cloud Network 2020  のビジョンアップデートと NSX-T Data Center 3.0 のご紹介
セッション＃2：VMware NSX Intelligence と分散IDS による新たなセキュリティのアプローチ
セッション＃3：VMware NSX Advanced Load Balancer とは！？
セッション＃4：Microsoft のクラウドソリューションを最適化する VMware SD-WAN by VeloCloudの最新動向
セッション＃5：オンプレだけじゃない、クラウドもSD-WAN も可視化
総括：

セッション＃1：Virtual Cloud Network 2020 のビジョンアップデートとNSX-T Data Center 3.0のご紹介

VMware が2018年にクラウド時代のネットワークをソフトウェアで再定義することの決意表明を“Virtual Cloud Network” というスローガンと共に表明して以降、約2年が経過しましたが、その後の開発、及びビジネス的なアップデートをさせていただくとともに最新のNSX-T Data Center 3.0 のサマリをご紹介させていただきました。

資料リンク：Virtual Cloud Networks のビジョンアップデートとNSX-T Data Center 3.0 のご紹介

お陰様でVirtual Cloud Network のコンセプトは多くのお客様に賛同いただき、ソフトウェアで構成するクラウド時代の新しいネットワークというコンセプトもだいぶ市民権を得られるようになってきました。引き続き様々な新製品開発、およびソリューション統合を予定しているので今後ともその発展を楽しみに待っていただきつつ、最新の NSX–T 3.0 で追加になった多種多様な新機能のごく一部のみをご紹介、といったお伝えしたい内容の多さに反比例した限られた時間でしたが、開発のスピード感やマルチクラウドネットワーキングに向けた方向性と勢いは感じ取っていただけたのではないかと思います。 

NSX-T 3.0では Day 2 Operation に対する自動化機能の拡張の一環として、Ansible におけるPolicy Module の追加拡張が行われたため、このセッションではこちらに関してのご紹介とともに以下のアンケートを実施しました。 

Q.1：これからのネットワーク、主にどんなインターフェイスで管理運用を行っていきたいですか？
Q.2：上記設問で API による自動化運用に興味があるとお答えの方に質問です。自動化ツールで主に興味があるのは以下のうちどれになりますか？
(回答総数：376)

そのアンケート結果がこちらです。

“今後の”ネットワーク運用において、これまでどおりの CLI をベースとしたネットワーク運用をメインの運用手法として考えておられる方の比率が思った以上に低いことが印象的でした。その反面、自動化運用への興味の高さが伺い知れます。 自動化ツールについては予想通り、国内においてはAnsible が人気のようです。

ダウンロード資料の最後に、付録として Ansible、Terraform から NSX-T の Policy Module を利用する際の最初の一歩について How To 解説を付録として入れておきましたので、自動化ツールを使って NSX-T をコントロールすることにご興味のある方がいらっしゃればそちらも参照いただければと思います。
また、NSX-T 3.0 より  Official  にFree Trialの評価版イメージの提供も開始しましたので、ネットワークの仮想化について実機評価されたい方は、ぜひお気軽にお試しください。
https://www.vmware.com/try-vmware.html 

セッション＃2：VMware NSX Intelligence と分散 IDS による新たなセキュリティのアプローチ

続いてのセッションは、「NSX-T 3.0 の数多ある機能拡張のうち一番世に伝えたい革新はなにか？！」と我々社員一同自問自答した結果、やはり「セキュリティ機能のさらなる革新であろう！」との結論に至り、特にその部分にフォーカスした NSX-T 3.0 における新機能群についてご紹介をさせていただきました。 

資料リンク：VMware NSX Intelligence と分散IDS による新たなセキュリティのアプローチ

特にこれまでアプライアンスでのみ提供されてきた IDS/IPS と言った高度なセキュリティ機能をNSX の分散サービスとして提供することができる、分散 IDS/IPS（IPS は次 Version で機能追加予定）という斬新なアーキテクチャについては相当なインパクトを持って（狙い通り！）受け取っていただけたようで、ここの部分について多数のライブ QA を頂きました。

頂いたご質問の中でもっとも多かったのは、「IDS/IPS  のシグネチャは、VMware が管理運営するのか？」というセキュリティの精度に関するごもっともな質問でした。QA でも返答させていただきましたが、回答としては「分散 IDS/IPS で利用できるシグネチャは複数の外部フィードを VMware が管理してハイパーバイザーに分散配備している」といった形となります。つまり今日現在は  VMware 自社製に加え 外部のプロのセキュリティ屋さんからシグネチャを受け取ってそれをハイパーバイザーに分散配備する、という形でセキュリティの精度を担保しています。この“複数の外部フィード”を取り込むことができるプラットフォームアーキテクチャ、というのが一番のカッコいいポイントでして、今後さらに複数のフィードを追加していくことで、多様化する脅威に包括的に対応できるようセキュリティ精度のさらなる向上を目指すことができる分散アーキテクチャプラットフォーム、というのが  NSX-T の技術的な特異点となります。
（最近 VMware はこのアプローチを Intrinsic Security と表現しています。 Intrinsic Security についてはそのうちまた別途詳しくご紹介します。）

このセッションでは、皆さまのセキュリティに対する取り組みに関わるコンデションについて、以下の設問をさせていただきました。 

Q.　ファイアウォールや IPS/IDS、どこに課題を感じますか？（複数回答可能）
(回答総数：391)

 そのアンケート結果がこちらです。

性能不足やトポロジーの複雑さ、冗長管理、といった導入コスト部分の課題のあるものの、それ以上にルール更新、ログ管理、運用に対する教育、などの運用コストに対する課題の比重の高さが伺えます。性能不足や冗長・トポロジー管理の煩雑さ、といった導入コストに対する問題点は NSX-T が提供する分散 Firewall・分散 IDS/IPS といったアーキテクチャ的な要素により大部分解決することができますが、仮想セキュリティならではの効率的な運用方法についても今後ご紹介できればと思います。

セッション＃3：VMware NSX Advanced Load Balancer とは！？

3つ目のセッションは、一昨年買収を発表させていただき昨年10月より国内でも販売が開始された旧  Avi Networks 改め、”NSX Advanced Load Balancer”（以下 NSX ALB ）についてのご紹介でした。NSX ALB は、我々 VMware のダイレクトタッチとしては最近ご提案させていただくことが非常に多くなってきているイチオシ製品、なのですが今回のセミナーのような形で広く多くの方にご紹介する、という意味では初お披露目の場となりました。 

資料リンク：VMware NSX Advanced Load Balancer とは！？

これまでハードウェア、もしくは仮想アプライアンスの形で提供されてきたロードバランサーというコンポーネントを、コントロールプレーンとデータプレーンを分離するという、所謂 SDN 的なアプローチにより再構築することによって分散型のデータプレーン配備と中央集中コントロール、及びそれによる自動化といった利点を提供することができる、マルチクラウド時代のアプリケーションデリバリー管理を行うために生まれてきた新世代のソフトウェア型ロードバランサーとなります。

NSX ALB は、旧来型ロードバランサーアプライアンスが Active/Standby という非常にリソース的な無駄を内包する HA アーキテクチャだったところと比べ、N+M の Active/Active 構成でデータプレーンを構成できる Elastic な HA 構成を提供できるのも大きな特徴です。これにより必要に応じたScale Out による拡張、及び Scale In による縮退を気軽に実行していただくことが可能になります。セッションではそのあたりの動作概要についてビデオでご紹介したところ、ライブ QA にて「あのデモ動画を共有いただくことはできないでしょうか？」というありがたいお言葉も多数いただきましたが、本製品のご紹介を記事化したリンクが以下に有り、この中にすでに動画デモもUpしておりますのでぜひご参照ください。
https://vmware-juku.jp/solutions/nsx-advanced-load-balancer/ 

また、いただいたライブ QA では「NSX-T Data Center が提供する LB 機能との差別化」についてのご質問も多数いただきました。NSX ALB は、“Advanced” Load Balancer  の名の通り、NSX-T Data Center が提供する LB 機能の上位版の位置づけな別製品となります。ただし今後、一部基本機能部分やUIの統合などの予定は NSX-T のロードマップにございますのでこちらも引き続き楽しみにしていていただければと思います。

このセッションでは、皆さまのクラウド活用に対する状況について、以下の設問をさせていただきました。 

Q.　クラウド環境の本番利用の予定はどの程度すすんでいますか？
(回答総数：293)

そのアンケート結果がこちらです。

約半数の方がすでに本番システムとしてクラウドの利用を開始済みなことが見て取れます。このうち、オンプレミスのシステムが完全に無いお客様の比率がどのくらいかはわかりませんが、おそらく多くのお客様がオンプレミスとクラウドのハイブリッド運用に着手し始めているということが想定されます。オンプレミスとクラウドで別仕様のロードバランサーを管理運用するか？もしくはオンプレミスのハードウェアロードバランサーの仮想アプライアンス版をクラウド上で動作させてさらなる管理ポイントの増加を否応なしに受け入れるか？でお悩みの皆さま、これを機にマルチクラウド管理を前提とした新しいソフトウェア型ロードバランサーをご検討頂いてはいかがでしょうか？！

セッション＃4：Microsoft のクラウドソリューションを最適化する VMware SD-WAN by VeloCloud の最新動向

4つ目のセッションは、少し毛色を変えて SD-WAN についてをご紹介するセッションを行いました。エンタープライズネットワークにおいてはおそらく今最も注目されている技術要素で、かつこの分野でマーケットリーダーとして認知されている SD-WAN by VeloCloud ですが、その差別化要素の最大のポイントはいかにクラウドと SaaS を有効活用するか、という点にフォーカスして練り上げられた製品特性が挙げれらます。今回のセッションでは特に Microsoft さまのサービスとの連携、親和性の高さにおける最新動向について様々なご紹介をさせていただきました。 

資料リンク：Microsoft  のクラウドソリューションを最適化する  VMware SD-WAN  by VeloCloud の最新動向

セッション内でも紹介していますが、Microsoft さまとの連携という観点では、

・Microsoft365（Office365） ネットワークパートナー
・Azure Virtual WAN (vWAN) 連携パートナー
・Azure VMware Solution (AVS)
・Azure Edge Zone 連携パートナー

と様々な Microsoft さま発のクラウドサービスを最適に使っていただけるネットワークサービスをVMware SD-WAN by VelocCoud としてご提供しています。このあたりの連携を柔軟にいち早くご提供できるのも VMware の SD-WAN がハードウェア特化型ではなく、完全ソフトウェア型の SD-WAN であることが大きなメリットとして寄与しています。 

また、ダウンロード資料には最後に、Azure 上のマーケットプレイスから仮想Edgeを構築して SD-WAN のスキーム組み込むためのにステップについての解説資料を付録として追加させていただいております。こちらをご覧になっていただければ如何に簡単に Cloud の世界を SD-WAN化 して接続させ、管理運用できるようになるか、をご理解いただけると思いますのでぜひご参照ください。

このセッションでは、ご紹介した VMware SD-WAN by VeloCloud と Microsoft さまのクラウドサービスの連携について質問させていただきました。 

Q.　本日ご紹介のソリューションで一番関心が高かったものはどちらでしょうか？
(回答総数：302)

そのアンケート結果がこちらです。

事前の社内予想としては、現時点で実案件にてご要望されることが最も多い Microsoft365（Office365）の最適化が圧倒的な比率を占めるのでは？と想定していたのですが、結果を見てみると「上記全て」という回答が同率一位の比率を締めていることや、「Virtual WAN との連携」に関するご興味も相当な比率を締めていることがわかり、改めて Microsoft さまにるクラウドサービスのパワーと注目度を認識する結果となりました。
Microsoft365（Office365）の最適化を行う SD-WAN という観点については、以前日本マイクロソフトさまと共同検証させていただいた際のホワイトペーパーをこちらからダウンロードいただくことも可能になっていますので、よろしければご参考にしていただければと思います。
https://vmware-juku.jp/resource/form_201/ 

また、現在 Virtual WAN についても日本マイクロソフトさまのご協力のもと共同検証を行っていますので、こちらについてもまた別の機会でご紹介できればと思っております。

セッション＃5：オンプレだけじゃない、クラウドもSD-WANも可視化

最後のセッションは、Virtual Cloud Network の名のもとにオンプレだけではなく、クラウド、およびSD-WANによるブランチサイトまでを含めた可視化とコントロールを担う、vRealize Network Insight（ちなみに、社内的には vRNI という略称から“バーニー”という愛称で呼ばれています）についてのご紹介でした。これまでは主に NSX for vSphere、もしくは NSX-T 環境に於ける仮想ネットワークと仮想セキュリティの可視化が vRNI の主な Value でしたが、近年ではこれがマルチクラウド、および SD-WAN の可視化と運用まで仕事領域を広げてきており、主にその部分についてのアップデートをさせていただきました。

資料リンク：オンプレだけじゃない、クラウドも SD-WAN も可視化

アップデートの中にはフローをベースにアプリケーションを検出して可視化する機能についての紹介もあったため、ライブ QA では、セッション＃2でも紹介があった、「NSX-T が提供するNSX Intelligence との棲み分けについて」のご質問もいくつかいただきました。確かに一部コンセプトが重複する点もありますが、NSX Intelligence は NSX-T Data Center が提供する DC 内の仮想ネットワークについての機械学習と分析、可視化に Deep にフォーカスするのに対して、vRNI は物理ネットワークやクラウドなど、必ずしも NSX-T Data Center を伴わない環境においても物理ネットワークと仮想ネットワークを一括で可視化、管理することを可能とするという形で進化をしていきます。

今年後半の Version Up では、昨年買収した Veriflow、Nyansa といった機械学習エンジンも今後vRNI のフレームワークに取り込んでいってさらに便利な仮想ネットワークの可視化運用ツールとして進化する予定ですのでこちらも引き続きご注目ください。

このセッションでは、ご紹介した vRNI を使ってどのようなネットワークを可視化、運用したいか、について質問させていただきました。 

Q.　可視化での運用をしたい・する予定のエリアはどれですか？（複数回答可能）
(回答総数：239)

そのアンケート結果がこちらです。

結果としては以前までのリリースにおけるアピール通り、NSX Data Center の可視化で利用したいという比率が最も多い結果となりました。これまで Cloud の可視化や SD-WAN の可視化についてのご紹介をあまり外部向けに行っていなかった関係もあっての比率だと思っておりますが、今回を機に NSX Data Center 部分以外に対してもご利用を検討いただければと思います。（セミナー後、SD-WAN の可視化ツールとしてのお問い合わせが急増しております！）

また、セッション内でもご紹介しましたがこれまでオンプレミスにアプライアンスを建てて使っていただくことがメインの vRNI でしたが、vRNI Cloud というクラウドサービスも開始されており（しかもすでに日本 Region の Cloud も開始済）、Free Evaluation も提供可能ですのでご興味持っていただけた方はぜひご検討ください！
https://cloud.vmware.com/network-insight-cloud 

総括：

今回のイベントは、緊急事態宣言が解除された直後のオンラインイベントとなりましたが、アンケート回答者のおよそ8割はご自宅からのご視聴でした。クラウドの本格化時代に向けた新しいネットワークのカタチを追い求めている昨今の VMware ですが、イベント開催後のアンケートからは参加者の皆さまも同様の課題とチャレンジに直面しているというフィードバックが多いように感じられました。

一方で、本イベントへの高いご評価とともにまだまだ 我々 VMware からの情報発信が足りないというお声も多数頂いており、New Normal の時代においてどのようなイベント、情報発信が最適かは我々としても模索が続いている中ですが、VMware  ネットワーク&セキュリティチーム一同、今後もより積極的な情報発信を心がけていき、“マルチクラウド時代における新しいネットワークのモデル”をお客さま、パートナーさまと一緒に日本市場にデリバリーしていければと考えておりますので、引き続きご愛顧のほどよろしくお願い申し上げます。 

〜お知らせ〜

 ※NSX-T Data Center、および VMware SD-WAN by VeloCloud について入門編から中級編まで各種セミナーも定期開催しております。
より詳細についてご興味を持っていただけたお客さまはこちらも併せてご参加をご検討ください。 

各種オンラインセミナーの開催日時はこちらから https://vmware-juku.jp/seminar/

• VMware が提唱する Cloud をつなげるための新時代のネットワークについて概要説明を聞いたみたい！という方はこちら
  → はじめてのネットワーク仮想化セミナー 〜Virtual Cloud Network とは〜 【オンライン開催】
• NSX-T Datacenterに関するより詳細な解説と動態デモ、デザイン、運用イメージについて説明を聞いたみたい！という方はこちら
  → ネットワーク仮想化セミナー 〜NSX データセンター編〜 【オンライン開催】
• VMware SD-WANに関するより詳細な解説と動態デモ、デザイン、運用イメージについて説明を聞いたみたい！という方はこちら
  → ネットワーク仮想化セミナー 〜VMware SD-WAN 編〜【オンライン開催】 

 ※VMwareでは、各種製品をクラウド上でご評価いただくHands-on Labs（HOL） という仕組みを無償でご提供しています。
今回ご紹介した各種ソリューションへの最初の一歩の入り口としてぜひご活用ください。

おすすめのHOLメニューはこちらから ( http://labs.hol.vmware.com/HOL/catalogs/catalog/1212 )

• HOL-2026-01-NET – VMware NSX-T: Getting Started
• HOL-2026-91-NET – VMware NSX-T Distributed Firewalling Lightning Lab
• HOL-2037-01-NET – VMware NSX Advanced Load Balancer (Avi Networks) – Getting Started
• HOL-2040-91-NET – Getting Started with VeloCloud Lightning lab
• HOL-2002-02-CMP – Network Insight and vRealize Network Insight – Getting Started 

The post 祝満員御礼：Virtual Cloud Network Day Live2020から見えてきた新たなネットワークのトレンド appeared first on Japan Cloud Infrastructure Blog.

データセンター内の通信に意外と多い HTTPS

「 NSX-T Data Center NSX 分散ファイアウォールとは 」もしくは、「マイクロセグメンテーション」とは、という記事もご紹介していきたいなと考えていますが、今回は 分散ファイアウォールを レイヤー７ファイアウォールとして利用する際の使い所をご紹介したいと思います。

NSX 分散ファイアウォールはざっくり言うと、
「 ハイパーバイザー で VM の vNIC 単位でインラインのステートフルファイアウォールが実行できる」機能です。通称、マイクロセグメンテーション（マイセグ）です。
NSX 分散ファイアウォールはハイパーバイザーとうまく連携することで、vCenter Server 全体で 全VM に対してフルカバレッジでステートフルファイアウォールを強制させることが得意です。

今ではデータセンター ネットワーク トライフィックの８−９割が、VM to VM や API to API といった East-West (E-W) の通信といわれています。こうした E-W 通信 も API連携 など、HTTPSによる 暗号化された通信が主流ですし、多くの製品の Webアクセスが今や HTTPS なのではないでしょうか。

SSL3.0 まだ使ってますか？

こうした HTTPS ですが、暗号アルゴリズムは何をご利用でしょうか。インフラ内での SSL/TLS の利用率をモニターしたり、端末のブラウザの設定の方で SSL3.0 の無効化と TLS の有効化 の 作業 に 着手されたりと いろいろと暗号アルゴリズムまつわる業務を 日々実施されていらっしゃるのかなと思います。

さて、２０２０年7月に、独立行政法人情報処理推進機構（IPA）さんの方から、「SSL3.0 を禁止します」という表現のガイドラインが出されたのは 記憶に新しいのではないでしょうか。

「TLS暗号設定ガイドライン～安全なウェブサイトのために（暗号設定対策編）～」 v3.0.1 のガイドラインの中で、「安全なウェブサイトの作り方」ということで とうとう SSL3.0の利用禁止 との表現となりました。

SSL3.0 については POODLE に代表されるような 既にいくつもの 暗号解読手法 や 中間者攻撃 のテクニックが公開され 攻撃者としては悪用しやすい状態が長年続いており、こうしたプロトコルを利用するには非常にリスクのある暗号アルゴリズムであるとの理解はされてきたものの、ブラウザの仕様や 長期間動作しているサーバが存在することにより、未だに陳腐化できてないプロトコルの１つであることも事実としてあります。

SSL3.0を無効化するには

では、SSL3.0 禁止 するにはどういった作業が 必要になるでしょうか。稼働中の 全てのアプライアンス や Webサーバの設定を見直したり、実際に SSL3.0 で繋いでみてみるなどの作業や、端末のブラウザ設定の方で SSL3.0無効化 と TLS有効化 の作業をしたり、またその 作業マニュアルの作成や 設定変更を実施したかの チェックリスト を運用したりと、、、

網羅的に実施を検討していくと 結構な工数となってしまいますし、端末やシステムの増減に 日々追従していかなければなりません。

NSX 分散ファイアウォールというアプローチ

こうした通信プロトコルを TLS だけに制御したい！といったことは、実は NSX 分散ファイアウォール が得意とします。NSX 分散ファイアウォール を レイヤー７ファイアウォール として使うことで、L7ルール として  SSL3.0 / TLS1.0 / 1.1 / 1.2 / 1.3  のような レイヤー７のプロトコル動作を チェックして、通信を 許可するか 禁止するかを 制御することができます。

この制御は、ステートフルファイアウォール として vCenter 基盤全体に対して 全VM 一括して 実施することができます。

例えば、「 443/TCP の TLS1.2 / 1.3 を許可するルール 」と「 443/TCP の SSL3.0 / TLS1.0 / 1.1 を拒否するルール 」を 分散ファイアウォール で運用してみます。すると、NSX-Tの基盤で 動作する Webサーバや 各種アプラアンス、そして HTTPS を使った API への アクセスに対して、TLS1.2 / 1.3  だけの 通信 が許可 され、SSL3.0 / TLS1.0 / 1.1 の通信 を 遮断 する 環境 ができてしまいます。

さらっと説明しましたが、よくよく考えると たったこの２行のルールを追加しただけで、急に サーバの免疫力が 強化されちゃいました。

Webサーバや 各種アプラアンスなどの 設定変更を行ったり、設定 抜け漏れがないかを 動作確認 してみたりといった作業 は、システムの増減に 日々追従させることを 前提に考えるとちょっと 現実的ではありません。

分散ファイアウォール を レイヤー７ファイアウォール として使うことで、たった ２行 の ルール追加 で この課題 を サクッとクリアすることができるんです。

また、vCenter 基盤全体に対して 全VM 一括して実施することができます。

まだある NSX 分散ファイアウォール の 活用術

また、「 443/TCP の SSL3.0 / TLS1.0 / 1.1 を 拒否するルール 」 というのは 運用で 非常に有効な情報源になります。443/TCP の SSL3.0 / TLS1.0 / 1.1 で 遮断された通信 は、ファイアウォール の ドロップイベントとして Syslogサーバで 確認することができます。

このログが 非常に有益です。このログの送信元IP と 宛先IPを 参照することで、どこの クライアント と サーバ 間 で、SSL3.0 / TLS1.0 / 1.1 が 使われそうになったか を 確認 することができます。この IPたちに対して、暗号アルゴリズム の 設定変更 を 検討したり、対処 の 抜け漏れ を 見える化 することもできます。

また、攻撃者が 利用するツール の中では、こうした 軽量で 古い暗号アルゴリズム で 実装され、大量のマルウェアが そうしたものを モジュールとして 流用していることもあり、こうした「攻撃に対する検知」にも活用できる利点もあったりします。

さらに、この 「 分散ファイアウォール での SSL3.0 / TLS1.0 / 1.1 の 拒否ルール  」を、３つ個別のルールに分割してそれぞれ 運用すれば、SSL3.0 / TLS1.0 / 1.1 それぞれが どれくらい使われそうになったかを、さらに絞り込んで確認することできますね。こうしたより細かい監視も、できるようになります。

詳細についてはまたいつか別の記事でご紹介しようと思いますが、VMware vRealize Log Insight  (vRLI)  という NSX-T ユーザーですとなんと無償で使える「ログ解析ツール 」がありまして、こちらを 使うとこんなふうに可視化してみせることも出来ます！

まとめ

さて、今回は主に NSX 分散ファイアウォール 周りに特化してご紹介させていただきました。NSX 分散ファイアウォール は、VM単位に シンプルなステートフルファイアウォール を提供しますが、ハイパーバイザー で 動作してくれるため、vCenter 基盤全体に対して 全VM 網羅的に 一括して 制御することが得意です。

これまで SSL3.0 を禁止するために、「 全てのサーバの設定を見直し、動作確認が必要だったり、システムが増えるたびに “このような作業” が都度発生してしまう 」といったような “ジレンマ” から、この運用にいつまで 耐えられるか？、と真剣に考えられた方もいらっしゃったのではないでしょうか。

そんな時には、NSX 分散ファイアウォールを ぜひご検討いただけたらと思います。

ゼロトラストを実現する仮想基盤を構築する上でも、こうしたセキュリティの健康診断が簡単に実施できて、作業負荷としてもきちんと運用できる範囲内であることが望まれます。NSX 分散ファイアウォール を レイヤー７ファイアウォール として使うことで、vCenter 基盤全体に対して 全VM 網羅的に  SSL3.0 対策が実施できます。

是非 NSX 分散ファイアウォール を活用してみてください。

〜お知らせ〜

 ※NSX-T Data Center、および VMware SD-WAN by VeloCloud について入門編から中級編まで各種セミナーも定期開催しております。
より詳細についてご興味を持っていただけたお客さまはこちらも併せてご参加をご検討ください。 

各種オンラインセミナーの開催日時はこちらから https://vmware-juku.jp/seminar/

• VMware が提唱する Cloud をつなげるための新時代のネットワークについて概要説明を聞いたみたい！という方はこちら
  → はじめてのネットワーク仮想化セミナー 〜Virtual Cloud Network とは〜 【オンライン開催】
• NSX-T Datacenterに関するより詳細な解説と動態デモ、デザイン、運用イメージについて説明を聞いたみたい！という方はこちら
  → ネットワーク仮想化セミナー 〜NSX データセンター編〜 【オンライン開催】
• VMware SD-WANに関するより詳細な解説と動態デモ、デザイン、運用イメージについて説明を聞いたみたい！という方はこちら
  → ネットワーク仮想化セミナー 〜VMware SD-WAN 編〜【オンライン開催】 

 ※VMwareでは、各種製品をクラウド上でご評価いただくHands-on Labs（HOL） という仕組みを無償でご提供しています。
今回ご紹介した各種ソリューションへの最初の一歩の入り口としてぜひご活用ください。

おすすめのHOLメニューはこちらから ( http://labs.hol.vmware.com/HOL/catalogs/catalog/1212 )

• HOL-2026-01-NET – VMware NSX-T: Getting Started
• HOL-2026-91-NET – VMware NSX-T Distributed Firewalling Lightning Lab

The post SSL3.0 を 簡単にシャットアウト！ NSX 分散ファイアウォール の L7 機能 appeared first on Japan Cloud Infrastructure Blog.

皆様こんにちは！株式会社ネットワールドの Dell EMC 製品担当です。

前回の予告通り、連載 4 回目は VxRail 上の「Intel® Optane SSD DC P4800 シリーズをキャッシュドライブで利用するとどれくらい性能が出たのか？」の検証結果についてご報告したいと思います！!

なお、VxRail は  VMware vSphere にストレージ機能 VMware vSAN 機能を標準搭載した VMware 社と Dell EMC 社が共同開発したハイパーコンバージド インフラストラクチャ (HCI) になります。VxRail の基本的な事や運用管理面に関して疑問をお持ちの方はぜひ、以前のブログをご参照下さい。

今回の検証内容としては以下を予定しています。

＜アジェンダ＞

• 検証環境

• パフォーマンス検証結果①

[ハードウェア構成]

モデル : Hybrid

キャッシュ : SSD

ネットワーク : 10GbE

•  パフォーマンス検証結果②

[ハードウェア構成]

モデル : All Flash

キャッシュ : Intel® Optane SSD

ネットワーク : 10GbE

•  パフォーマンス検証結果③

[ハードウェア構成]

モデル : All Flash

キャッシュ : Intel® Optane SSD

ネットワーク : 25GbE

検証環境

まずは、検証環境についてご紹介いたします。

◆VxRail

キャッシュ層に Intel® Optane SSD DC P4800X シリーズを搭載した VxRail E560F (All-Flash Model) を 4 ノード使用してクラスタを構築いたしました。

◆ToR スイッチ

Dell PowerSwitch S5212-F を 2 台を Virtual Link Trunking (以下、VLT) で冗長化した構成で構築いたしました。ケーブルも SFP28 モジュールの Twinax ケーブルを使用しているため、最大リンクスピードは 25G となりますが、まずは現在主流の 10GbE ネットワークを模擬するため、10G にてリンクアップさせております。

上記構成なので、通常時 vSAN のトラフィックは、スイッチ#2 側にて処理をする構成となっております。

• E560F 単体でのスペックは下記の通りです (各ノードで同一構成となります)

CPU : Intel(R) Xeon(R) Gold 6230 CPU @ 2.10GHz * 2socket

Memory : DDR4 32GB * 12 =384GB

Cache Disk : Intel® Optane SSD DC P4800X 375GB * 2

Capacity Disk : 1.75TB SSD * 4

NIC : Broadcom Dual 25Gb Ethernet

• キャッシュディスクとして使用する Intel® Optane SSD DC P4800X
  のスペックは、以下の通りです。

ベンチマークの測定は、VMware 社が提供している [HCIBench] を使用しました。

これ一つで負荷掛け用仮想マシンのデプロイから、ワークロード作成、負荷掛け、測定結果のまとめまで自動でできる便利なベンチマーク測定自動化ツールです。
実際に負荷をかけるベンチマークツールが別途必要で、[vdbench] か [FIO] から選択する必要がありますが、今回は [vdbench] を使用します。

実際に負荷をかけるにあたって、ワークロードを作成する必要があります。
vSAN に関するワークロードの作成指標は、弊社内でもかなり試行錯誤しましたが、以下の作成指標にたどり着きました。

Read/Write で 5 パターン、Random/Sequential で 5 パターン、計 25 パターンのワークロードで 1 セットとしました。

VxRail では、デプロイ後 FTT=1 のストレージポリシー (SPBM : Storage Policy Based Management) がデフォルトで適用されています。従って、通常は以下のような Read/Write のデータフローとなります。

vSphere 6.7 版の VxRail では、デプロイすると vSAN データストア上に [vCenter Server Appliance]、[外部PSC]、[VxRail Manager] が構成されます。（以下、VxRail 用管理 VM）

また、HCIBench 用の仮想マシンとして、[コントローラ VM]、[負荷掛け用ゲスト VM] が作成されますが、これらの VxRail 用管理 VM や、コントローラ VM、負荷掛け用ゲスト VM は、ベンチマークを測定するリソースを用いないほうが測定結果としてはより正確なものが計測できますが、弊社検証機材の制約等からすべて同一のクラスタ/データストア上に配置して測定しました。そのため、テスト結果は参考としてご活用ください。

• パフォーマンス検証結果①

Hybrid モデルでのパフォーマンス測定

まずは、非 Optane キャッシュの VxRail でどれぐらいの性能が出るのか指標を測定してみます。
検証機材として、VxRail E560 (Hybrid) のクラスタがありましたので、そちらでベンチマークを測定してみます。各ノードのスペックは、下記のとおりです。

こちらも同様に、E560 のクラスタ上に HCIBench をデプロイし、ベンチマークを測定してみました。

◆パフォーマンス (参考)

今回、これから Intel® Optane SSD との比較を行うためのベースラインとなるパフォーマンステストを十分、行いました。パフォーマンス結果そのものは紙面の都合上、本ブログでは公表できませんが、既存の 3Tier ディスクや他社 HCI と比べても何ら遜色ない (むしろ十分早い!!) パフォーマンス結果を確認することができました。

(Networld では、”IOPS” / “スループット” / “遅延” をランダム IO・シーケンシャル IO・書き込み IO / 読み込み IO と HCI ベンチのワークロードタイプ毎にデータ収集を行っております。詳しい値を確認したい方はぜひ、Networld 担当営業までご連絡ください)

では、Hybrid モデルでのベースとなるパフォーマンス傾向も見えてきた為、早速、Intel® Optane SSD 搭載の All-Flash モデルでのパフォーマンスを確認していきましょう。

•  パフォーマンス検証結果②

② All-Flash Optane キャッシュ (10GbE) でのパフォーマンス

◆IOPS (参考値)

Hybird 構成と同じ種類の IO を流したところ、約 4.6 ～ 4.9 倍近くのパフォーマンス結果となりました。

◆スループット (参考値)

Hybird 構成と同じ種類の IO を流したところ、約 4.7 ～ 4.8 倍近くのパフォーマンス結果となりました。

◆遅延 (参考値)

Hybrid 構成と比較して、パフォーマンス面で 4.6 ～ 4.9 倍近いパフォーマンスを出しながら、遅延という側面では、約 1/3 程度の遅延になっていることが確認することができました。

現状でもオールフラッシュディスク等と比べても十分満足のいくパフォーマンスを計測しておりますが、ToR スイッチの状況を確認してみると、vSAN の 10G  ネットワーク部分から大量のパケットドロップが発生していることを発見しました。

show interface status コマンド抜粋

==============================================================================

【Ethernet 1/1/1】
Input statistics:
0 CRC, 0 overrun, 0 discarded
Output statistics:
0 throttles, 13 discarded, 0 Collisions, wred drops

【Ethernet 1/1/2】
Input statistics:
0 CRC, 0 overrun, 0 discarded
Output statistics:
0 throttles, 4294967185 discarded, 0 Collisions, wred drops

【Ethernet 1/1/3】
Input statistics:
0 CRC, 0 overrun, 0 discarded
Output statistics:
0 throttles, 4294967180 discarded, 0 Collisions, wred drops

【Ethernet 1/1/4】
Input statistics:
0 CRC, 0 overrun, 0 discarded
Output statistics:
0 throttles, 4294967165 discarded, 0 Collisions, wred drops

==============================================================================

どうやら、ネットワークの帯域がボトルネックとなっている模様です。ここのネットワーク帯域を解消することにより、Intel® Optane SSD 搭載の VxRail はもっとすごいパフォーマンスを発揮するのではないでしょうか。

という事で、引き続き、Intel® Optane SSD 搭載の VxRail のパフォーマンスチューニングを実施していきたいと思います。

今回の記事はこの位にさせて頂き、次回の第 5 回では、vSAN ネットワークの帯域を 25G に変更したり、ジャンボフレームを有効にする等、Intel® Optane SSD のパフォーマンスを更に引き出していきたいと思います。

なお、Networld では、本ブログでご紹介している全ての検証パターン (Read・Write はもちろん、ランダム、シーケンシャル等) の様々な IO パターンでの検証結果を収集しております。本 Blog では紙面の都合上、全てのパフォーマンス結果をご紹介させて頂いておりませんが、皆様の環境の参考になる様な検証結果も持ち合わせておりますので、ぜひ、お気軽に Networld 担当営業までお声がけください。

では、次回もお楽しみに

The post ネットワールド的検証結果報告 Part-1 (VxRail Intel Optane ™ SSD のパフォーマンスはどの位出るのか!?) appeared first on Japan Cloud Infrastructure Blog.

VMware SD-WAN by VeloCloud は Microsoft Azure Virtual WAN と Microsoft 365 のネットワーク認証パートナーです

近年、様々なソフトウェアサービスがクラウドで提供されるようになり、それらサービスの企業活動における業務利用も一般化しつつあります。（VMware のクラウドソリューションはこちら！）特に Microsoft が提供する Microsoft 365 (旧称Office 365) は、Software as a Service (SaaS) を代表するサービスとして多くのユーザーに利用されております。しかしながら現在の企業 WAN ネットワークは、クラウド利用に最適化されておらず、様々な課題が顕在化するようになってきています。

本稿では、このような課題を解決する VMware SD-WAN by VeloCloud (以下 VMware SD-WAN) の特徴、ならびに Microsoft 365 との親和性について紹介していきます。

コンテンツ：
なぜ VMware SD-WAN はクラウドソリューションとの親和性が高いのか
Microsoft 365 利用を最適化するネットワークとは

なぜ VMware SD-WAN はクラウドソリューションとの親和性が高いのか

VMware SD-WAN はクラウド時代に最適な企業 WAN 構築を実現するソリューションです。これまでの企業 WAN は自社データセンター・本社ネットワークに業務トラフィックを集中させ、インターネットへのアクセスも一元的に制御を行うバックホール接続と呼ばれる構成が一般的でした。（図1 上図）

しかしながら、クラウド向け通信が劇的に増えることで、拠点サイトの回線帯域が不足し、データセンターの出口のファイアウォールやプロキシの性能不足が想定されます。クラウド利用を加速するには回線帯域の増強やファイアウォール・プロキシの増設等が必要になりコスト増加が想定されます。また常にデータセンター経由の通信となるため、定常的な通信遅延が発生してしまいます。

このような課題を解決し、ネットワーク構成を最適化できるソリューションが VMware SD-WAN です。（図1 下図）

これまでの企業 WAN はセキュリティの観点から閉域網の利用が多く見受けられますが、VMware SD-WAN を利用することで、安価で高速なブロードバンドインターネット回線も企業 WAN 回線に組み込むことが可能です。閉域回線とインターネット回線を束ねて利用することもできるため、ビジネス状況に合わせた回線帯域の増強、柔軟な移行が可能となります。

また最適な通信経路を容易に・柔軟に制御が可能な点も VMware SD-WAN の特徴です。拠点サイトからデータセンターを介さず直接クラウドへ通信させるローカルブレークアウトと呼ばれる経路制御が容易に可能で、制御対象の通信もアプリケーション単位で実施できます。

これら設定はシンプルな Web ユーザーインターフェースから全て実施が可能で、VMware SD-WAN では従来のルータ設定で用いられる複雑な CLI (Command Line Interface) を覚える労力は一切不要です。

図1 クラウド時代の企業 WAN の課題（上図）とVMware SD-WAN による解決（下図）

ユーザーのクラウド利用・体感を最適化するネットワークを提供できるのは、VMware SD-WAN の最大の特徴でもあります。

VMware SD-WAN は Microsoft とアライアンス関係をもち、Microsoft 365、Azure Virtual WAN、Azure Edge Zones、Azure VMware Solution (AVS) といったクラウドソリューション利用を最適化するネットワークサービスをご提供致します。ここではクラウド利用を最適化するVMware SD-WAN の２つの特徴をご紹介致します。

１つ目は、ベストエフォート型のインターネット回線もビジネスクオリティに回線品質改善を行う Dynamic Multi-Path Optimization (DMPO) です。（図2）

DMPO は VMware SD-WAN 独自の技術で、回線のモニタリング、パケット単位での動的な通信制御、また回線状況に応じた品質改善を提供します。回線品質は遅延・ジッター・パケットロスの観点から10点満点でスコアリングされており、以下の例では回線自体のスコアが6.72点/10点であるのに対して、DMPO の品質改善効果により9.96点/10点まで向上しているのがわかります。

図2 VMware SD-WAN の回線品質保証 (DMPO)

２つ目の特徴は、VMware が管理・提供するクラウド型のソリューション、VMware SD-WAN クラウドゲートウェイです。（図3）

先程ご紹介した DMPO は VMware SD-WAN エッジと呼ばれるデバイス間で構成される SD-WAN オーバーレイ上で提供可能な機能となります。このため通常はクラウド向け通信については SD-WAN オーバーレイを提供するのが困難となりますが、このクラウドゲートウェイを利用することで、クラウド利用時も SD-WAN オーバーレイ上の DMPO 機能をご利用頂くことが可能です。

このことはクラウド利用のユーザー体感向上に大きく寄与します。通常、ベストエフォート型インターネット回線は拠点からの回線出口でトラフィック輻輳が頻発します。この問題は、単純に拠点からローカルブレークアウトにより直接クラウド向けに通信をするだけでは回避できない問題となり、クラウド利用のユーザー体感を大きく下げることが想定されます。クラウドゲートウェイを用いた通信では、拠点出口での輻輳箇所においても DMPO の恩恵を受けることができるため、ユーザーのクラウド利用体感を最適化・向上することが可能となるのです。

図3 VMware SD-WAN クラウドゲートウェイによる SaaS/IaaS へのオーバーレイによるアクセス

Microsoft 365 利用を最適化するネットワークとは

クラウド利用に最適なネットワークといった場合、どのような観点で対策を検討すればよいのでしょうか。

その問に非常に有益な見解を Microsoft は公開しており、Microsoft 365 利用における環境構築の指標となっています。Microsoft は、このネットワーク要件を実現できるソリューションに対して認定を行っており、VMware SD-WAN も “Microsoft 365 Networking Partners” ソリューションとしてリスト頂いており、Microsoft 365 との接続性は十分に検証済みとなっています。

ローカルブレークアウトを活用し自社データセンター等を介さず直接 Microsoft のクラウド環境へアクセスすることで、SaaS アプリケーションのパフォーマンスを最適化することができます。さらにVMware SD-WAN のソリューションでは、世界中に配備された VMware SD-WAN クラウドゲートウェイを介してSD-WAN の回線品質最適化が SaaS アプリケーションへも適用できるため、企業ユーザーは拠点に VMware SD-WAN エッジを導入するだけで、SaaS 向け通信の品質もビジネスクオリティに改善して通信を行うことが可能となります。（図4）

弊社のアジア地域での検証では、品質が優れないインターネット回線の環境においても、ローカルブレークアウトのみの通信制御と比べ、VMware SD-WAN クラウドゲートウェイを使用することで Microsoft 365 への通信のスループットを約10倍改善したという例も報告されております。

このような効果を拠点側のエッジ機材導入のみで実現できるのは、VMware SD-WAN の非常に大きな強みとなります。

図4 VMware SD-WAN クラウドゲートウェイにより Microsoft 365 へのアクセスを最適化

VMware は日本マイクロソフトと共同で、Microsoft 365 のパフォーマンスとネットワークの関係性から、その最適化手法について検証を通して確認を行いました。こちらについて、検証結果並びに考察をまとめたホワイトペーパーをこちらよりダウンロード頂けますのでぜひ御覧ください。

まとめ

本稿では、VMware SD-WAN by VeloCloud とクラウドソリューションとの親和性についてご紹介しました。また Microsoft 365 と VMware SD-WAN の連携について、特徴や連携させることのメリットについてご紹介しました。クラウドの世界では日々ソリューションが進化している状況かと思います。ユーザー様で、こんな使い方はできないのか、などございましたら、ぜひお気軽に弊社までお問い合わせください。

こちらの投稿でご紹介したソリューション詳細について、2020年5月にウェビナー「Microsoft のクラウドソリューションを最適化するVMware SD-WAN の最新動向」においても詳細をご紹介しております。現在はセッション資料・動画は VMware Evolve Online にて公開中のため、ぜひ合わせて御覧ください。

VMware SD-WAN とクラウドに関連するお話は別の記事でもご紹介しておりますので、合わせてご覧ください。

VMware SD-WAN でクラウド上に仮想拠点を建てる話 (Coming Soon)

Microsoft Azure Virtual WAN が SD-WAN と実現する次世代企業ネットワークとは (Coming Soon)

免責事項

• 本稿でご紹介の VMware SD-WAN by VeloCloud のソリューションは一部開発中のものも含まれております。今後詳細が変更となる可能性もございますことご了承ください。
• 本稿で記載の Microsoft ソリューション説明については、内容の完全性を担保するものではございません。Microsoft ソリューション詳細につきましては、全て Microsoft 社からの情報が優先されますこと、ご了承ください。

参考情報

VMwareのイベント情報

今後のオンラインセミナー実施予定などはこちらからご確認頂けます

VMware ハンズオンラボ

ハンズオンラボは、VMwareの最新の製品やソリューションを、様々なシナリオに沿って、オンデマンドで利用することができます。VMware SD-WAN 入門としては以下コースがございますのでご参照下さい。

• • HOL-2040-91-NET – Getting Started with VeloCloud Lightning lab

VMware SD-WAN by VeloCloud の最新情報 (英語)

VMware SD-WAN の最新情報はこちらでご紹介しております。

ヴイエムウェア営業へご連絡を希望される場合は下記URLのフォームよりお問い合わせください。

https://www.vmware.com/jp/company/contact_sales.html

The post なぜ VMware SD-WAN by VeloCloud はクラウド時代の企業 WAN に最適なソリューションであるのか appeared first on Japan Cloud Infrastructure Blog.