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 製品担当です。
連載 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 VMware Japan Blog.

みなさま、こんにちは。VMwareの児島です。先日開催された「Digital Workspace Day – LIVE ～事業継続対策として有効なテレワークを実現するには？」のセッション紹介記事第三弾です。私が担当しました「VPN に依存しない、テレワーク時代を見据えたアプリケーションアクセス〜ゼロトラストセキュリティ」をダイジェスト版としてご紹介いたします。
より詳細な内容を知りたいと思っていただけた方は「EVOLVE ONLINE」（記事下部にログインリンク掲載）にご登録・ログインいただくことで、当日の収録動画および資料がダウンロードが可能です。是非、アクセスのほどよろしくお願いいたします。
 

「これからの時代に必要な事業継続のカギは」

緊急事態宣言が発令されたことにより、多くのみなさまが今までとは違う働き方への実現に取り組まれたかと思います。しかし、前例のないこの状況下においては手探りで事業継続対策をされた方も多いのではないでしょうか。本セッションではこの状況下で発生しうる下記のような課題に触れ、利便性低下やセキュリティ懸念と言った課題に対してどのようなアプローチが有効なのか、事業継続に必要なポイントについて整理しお話をさせていただきました。

• 物理的な課題
  -社給デバイスを持ち帰れない。（業務ポリシー上で禁止であったり、端末がデスクトップ型であるなど）
  -社員全員分の在宅勤務用パソコンが無い（一部の利用者にしか配布していないなど）
• 業務アプリに対する課題
  -VPN接続が不安定
  -普段利用している業務アプリが社外から利用できない（業務ポリシー上禁止であったり、ネットワーク負荷により）
• セキュリティに関する課題
  -前例がない状況下のため、漠然とした不安がある。

図1:テレワーク実施時に直面した課題

 
また当日は参加者の皆様にオンラインアンケートを実施せていただき、リアルなご意見を頂戴いたしました。こちらの結果もEVOLVE ONLINEに掲載されておりますので是非ご確認ください。
 
 

「ゼロトラストセキュリティって？」

最近よくITセキュリティの分野で耳にすることが多い「ゼロトラストセキュリティ」。復習も兼ねた概要のご説明に加えて従来の境界型セキュリティモデルとの比較や、この状況下においてゼロトラストセキュリティモデルがどのように有効なのかをセッションではご紹介しています。

図2:ゼロトラストセキュリティとは

「Workspace ONEで実現するゼロトラストセキュリティなテレワーク環境とは？！」

当日のセッションではVMwareが考えるゼロトラストセキュリティモデルと、VMware Horizonも含めたVMware Workspace ONE （以下、Workspace ONE） プラットフォームの各製品がそれぞれどのような役目を担うのか、またどのようにゼロトラストセキュリティを実現していくのかユースケースと共にご紹介いたしました。

図3:ゼロトラスト5つの柱と可視化/分析、自動化

図4:Workspace ONEによるゼロトラストセキュリティモデルのアプリケーションアクセス

 
テレワーク環境下における業務継続やゼロトラストセキュリティの実現ににご興味がある方は、是非「EVOLVE ONLINE」にご登録・ログインいただき、当日の収録動画および資料を参照していただけますと幸いです。また、「EVOLVE ONLINE」では、EUC のソリューションだけでなく、その他様々なコンテンツを提供しております。お客様の抱えられている課題に対する解決策がきっと見つかると思います。
———-
【講演資料について】
下記の URL より EVOLVE ONLINE にご登録いただき、マイページより資料・動画をご確認いただけますので、是非、ご活用ください。
EVOLVE ONLINE
EVOLVE ONLINE ご登録＞マイページ＞「ウェビナーを視聴する」メニュー
———-
最後まで、読んで頂きましてまことにありがとうございました。

The post テレワークを実施してみたけれども・・・リアルなお悩みとは？!　Workspace ONEで本当に必要なテレワーク環境を実現 appeared first on VMware Japan Blog.

みなさまこんにちは。 VMware Educationチームです。

例年2月に開催しておりました『VMware Education Partner Day』ですが、2020年は
企画段階で世の中が在宅勤務にシフトし、一堂に会することが難しい状況となりました。

ビジネスセッション、Award Partyを含むPartner Dayの場で贈呈させていただきたかった
Partner Awardですが、本年はトロフィーを対象の皆さま方に送付させていただき、Blogにて
ご紹介させていただくことといたしました。

以下のパートナー様、VMware Certified Instructorの皆さま方に、2019年のVMware Education
ビジネスに特にご貢献いただいた感謝を込めて、Awardを贈呈させていただきます。

《VMware Education Partner of the Year 2019》
CTC テクノロジー株式会社 様

《VMware Education Partner Award 2019》
株式会社富士通ラーニングメディア 様

《VMware Certified Instructor Award 2019》
(氏名50音順)

千田 泰史 様 (日本サード・パーティ株式会社)

二岡 祐介 様

間所 徹雄 様 (日本ヒューレット・パッカード株式会社)

盛  洋史 様 (CTCテクノロジー株式会社)

受賞されたVCIの皆さま、パートナー様のみならず、VMware Education サービスに関わる
全ての皆さまに感謝申し上げます。

今後とも、VMware ならびにVMware Educationサービスのビジネスの発展へのご協力を
よろしくお願い申し上げます。

The post VMware Education Partner Award 2019 appeared first on VMware Japan Blog.

みなさま、こんにちは。VMware の森です。
 
先日開催されました、オンラインイベント「Digital Workspace Day – LIVE ～事業継続対策として有効なテレワークを実現するには？」のセッション紹介記事をお送りします。私が担当させていただきました、「事業継続を支えるデバイス選択の可能性〜戦略的 BYOD、既存資産の有効活用術〜」の概要をご紹介します。
より詳細な内容につきましては、「EVOLVE ONLINE」（記事下部にログインリンク掲載）にご登録・ログインいただくことで、当日の収録動画および資料がダウンロードが可能です。アクセスいただけますと幸いです。
 

「事業継続を支えるデバイス選択の可能性〜戦略的 BYOD、既存資産の有効活用術〜」

昨今の社会情勢から、緊急事態宣言が発令されるなどの状況における事業継続に、危機感を抱いている企業担当者様も多くいらっしゃるのではないでしょうか。事業継続のためには、場所にとらわれず勤務できるテレワークなどの体制が必要ですが、一方で、テレワークに関する多くの課題も浮き彫りになってきました。このセッションでは、課題の１つである「テレワークに利用できるデバイスの選択」を取り上げ、考えうる選択肢を検討し、具体的なユースケースをご紹介しています。

 
通常業務でノートPCを利用しているユーザーはデバイスを持ち帰ることができるので、テレワーク移行のハードルは比較的低いと考えられます。それ以外のユーザーのデバイスをどのように調達するのが企業にとってベストなのか。その選択肢として、本セッションでは、「キオスク端末ユースケース」、「戦略的 BYOD ユースケース」の２つのユースケースをご紹介しています。
 

「キオスク端末ユースケース」

全ての社員のテレワーク業務用のデバイスを新規に調達するのは、コスト的にも時間的にもハードルが高く、運用の手間もかかります。そこで、新規調達の代わりに、社内遊休資産の低スペックマシンを、業務用途を限定した「キオスク端末」として簡易キッティングするというユースケースをご紹介しています。
 

 
Workspace ONE UEM (統合エンドポイント管理) では、PC を特定アプリ限定用途に「キオスクモード」として構成できる機能があります。それを用いたユースケースには、以下の特徴があります。
・ユーザーには、あらかじめ定義されたアプリケーションへのアクセスのみ許可されており、システム操作などは許可されないので、セキュリティ強度が高い。テレワーク、リモートワーク用途に向いている。
・限られたアプリケーションしか利用できないので、過剰なリソースを必要としない。企業の遊休資産となっている低スペック PC を活用することができる。
・Workspace ONE UEM が提供する Per App VPN、VMware Horizon （ハイブリッド/マルチ クラウドに対応したデスクトップおよびアプリケーションの仮想化ソリューション）との相性が良い。
・用途を限定しているので、管理者にとっても管理負荷が小さい。
 
一般的には馴染みが薄い、テレワークでのキオスク端末活用ケースになりますが、余剰の遊休資産があるケースでは検討の価値があるかと思います。
 

「戦略的 BYOD ユースケース」

全社員への社給デバイス支給がコスト面などでハードルが高い場合、BYOD (Bring Your Own Device)で社員のデバイスを利用しての業務が選択肢になりえます。従来、BYOD は、セキュリティ面、プライバシー面、管理負荷面、などから導入が困難とされており、日本での普及は進んでいるとは言えません。導入されたとしても、一部のモバイル端末で希望者のみの利用、利用用途もメール閲覧のみ、といった限定的な用途でした。
 
ところが、Workspace ONE のようなデバイスの種類を問わず一元管理できる UEM (Unified Endpoint Management) 製品の登場により、社内だけでなく、社外の様々なデバイスの管理もハードルが下がってきています。加えて、昨今のテレワーク需要により、本気で BYOD を検討する企業も増えて参りました。ここでは、モバイルデバイスでメールを見る程度の BYOD ではなく、事業継続のために社員所有の PC デバイスで自宅で業務を実施するための、「戦略的 BYOD ユースケース」をご紹介しています。
 

 
Workspace ONE は、BYOD 運用のための様々な機能を備えています。このユースケースには、以下の特徴があります。
・ユーザーのプライバシーに配慮して、管理のために必要最低限のデータのみを取得。(位置情報、個人導入アプリ、などは取得しない)
・管理者からは、ユーザー個人の利用に影響する管理コマンド実行ができなくなっている。(デバイス初期化、デバイス再起動、などは実行できない)
・ユーザーから、BYOD 管理で取得されるデータを確認することができる。
・BYOD 利用が必要なくなったら、管理者は「企業情報ワイプ」により、配布された証明書やアプリなど、企業情報のみを削除することができる。
・Per App VPN や 多要素認証の活用により、社内リソース、社外 SaaS に対してセキュアなアクセスを実現することができる。
 
事業継続の観点からも、いざという時に備えて、PC デバイスの BYOD 運用を検討しておくことも必要かと思います。検討の一助になれば幸いです。
 

「まとめ・ ユースケース比較」

本セッションのまとめとして、これまでにご紹介した「キオスク端末ユースケース」、「戦略的 BYOD ユースケース」に加え、「社給 PC 利用ユースケース」のそれぞれの特徴を比較しています（詳細は、EVOLVE ONLINE のセッション資料参照）。テレワーク導入におけるデバイス検討に役立てて頂けますと幸いです。
 
事業継続のためのデバイスをどのような形で導入、運用するかお悩みの方は、是非、「EVOLVE ONLINE」にご登録・ログインいただき、当日の収録動画および資料を参照していただけますと幸いです。
 
———-
【講演資料について】
下記の URL より EVOLVE ONLINE にご登録いただき、マイページより資料・動画をご確認いただけますので、是非、ご活用ください。
EVOLVE ONLINE
EVOLVE ONLINE ご登録＞マイページ＞「ウェビナーを視聴する」メニュー
———-
最後まで、読んで頂きましてまことにありがとうございます。

The post 遊休資産、個人所有 PC をフル活用！〜テレワークを支えるデバイス選択の可能性〜 appeared first on VMware Japan 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 VMware Japan 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 VMware Japan 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 VMware Japan 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 分散ファイアウォールを ぜひご検討いただけたらと思います。

NIST（米国標準技術研究所）でゼロトラストアーキテクチャー(ZTA)の定義が進んでおり、2020年8月に「NIST SP 800-207 Zero Trust Architecture (Final) 」が発行されました。こちらの第３章では、具体的な実装技術に言及して ゼロトラストアーキテクチャアプローチ を定義していて、論理コンポーネント（具体的な実装技術）として、３つの要素を提示しており、その２つ目に、マイクロセグメンテーションという言葉が使われるようになりました。「マイクロセグメンテーションによって、ワークロード（リソース）をセグメント化し、全てのワークロードに認証と認可により、ワークロードへの必要最小限のアクセス範囲を動的にできること」といったことが示されています。こうしたアーキテクチャーの定義を実現を目指しつつ、ゼロトラストを実現する仮想基盤を構築する上でも、上記でご紹介してきましたセキュリティの健康診断が簡単に実施できて、作業負荷としてもきちんと運用できる範囲内であることが望まれるかと思います。例えば１つの活用例として、NSX 分散ファイアウォール を レイヤー７ファイアウォール として使うことで、vCenter 基盤全体に対して 全VM 網羅的に  SSL3.0 対策が実施できます。SSL3.0はあくまで一例にはなりますが、皆様のゼロトラスト実現に向けてこうした考え方がご参考になれば幸いです。

NIST SP 800-207で定義された原則やマイクロセグメンテーションは、重要なトピックになります。分散ファイアウォールとの関係ついては、また他のブログで深く触れたいと思います。

是非 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 VMware Japan Blog.

ネットワークセキュリティをビルトインでシンプルに使う

多くの企業が更なるビジネス上のメリットやスピードを促進するため、大量のアプリケーションを運用し、企業システムは一元管理されたデータセンターから分散化され、ネットワークとセキュリティが複雑化しています。これらに対応するため、VMware ではアプリケーション指向のソフトウェア定義型セキュリティをインフラに内在させる新たなアプローチを進めており、その最新セキュリティソリューションの１つである VMware NSX Data Center 分散IDS/IPS を解説したいと思います。

ネットワークによる内部セキュリティ対策の難しさ

最近では、 3-Tire App と言った階層化やマイクロサービス化して組むように、構成がより複雑になったり短命な数千のサービスをリアルタイムに管理・保護していく必要が出てきていますが、本記事のご覧の皆様はどのようにこうした構成のシステムを運用されていますでしょうか？

こうした構成が年々高度で複雑になってくることで、セキュリティインシデントが生じた際に影響範囲を把握したり、問題をトレースしてくのが非常にタフな作業になってきていることがわかってきました。

5月に行った弊社イベントにおける来場者アンケートでも、多くの皆様がセキュリティの運用面に大きな課題を感じておられるようでした。

皆様も運用される中で、こうした難しさに類似したことを感じられたことがあるのではないでしょうか。

こうしたシステム構成の中で、内部の繋がりに対する ネットワークセキュリティ対策として、構成情報や通信フローを見える化したり、実通信をブロックしていこうとしても、思った粒度でうまく実施できないと言った課題があります。また、セキュリティカバー範囲を細くしていくと逆に運用が複雑になってしまう課題もあり、この２つの課題の板挟み状態に日々お悩みなのではと思います。このバランスのトレードオフを考慮しつつ 現状稼働中のアーキテクチャで運用しなければいけませんので、これ以上セキュリティカバー範囲を細かくできずに、セキュリティ対策として どうしても抜け漏れが生じてしまいます。

このように内部の繋がりに対するのセキュリティ対策の難しさが逆手にとられ、昨今の脅威では 攻撃者は約 3ヶ月間 システム内部を潜伏することができ、クレデンシャルを入手する活動の成功率をあげてしまう結果を導いしてしまっていることが複数のセキュリティ調査機関から報告されています。

VMware が目指す ビルトインアプローチとは

これまでのアプローチは、インフラの上にゲートウェイやアプライアンスと言ったセキュリティを足してつけるような、いわゆるボルトオンのアプローチとなり、処理性能のボトルネックになったり、アプライアンスでは処理がカバーできないために検査対象のトラフィックを取捨選択したり間引く必要があり、盲点ができてしまいます。さらには、仮想化されたデータセンターの場合、ワークロードが他のホストや他のデータセンターに vMotion を使用して移行する世界ですので、従来型の場合は、ワークロードの移動に合わせて、セキュリティ設定を追従させるのが困難でした。

VMware はこうしたこれまでのアプローチから、新たなアプローチを提供しています。こうしたお家のセキュリティのように、ビルトインといったあらかじめ組み込まれた状態でセキュリティ対策をシンプルに、そして抜け漏れがないビルトインのアプローチを製品やソリューションに取り込んできています。

NSX 分散IDS/IPS とは

NSX 分散IDS/IPS は、VMware Software-Defined Data Center（SDDC）にビルトインの形で IDS/IPS を提供してくれる、新しいアプローチのセキュリティ対策になります。NSX がこれまで提供していました分散ファイアウォールや分散スイッチと同じように、ハイパーバイザーに組み込んだ分散アーキテクチャを採用しています。

これにより、クラウドのネットワークファブリックに、IDS/IPS をビルトインすることができます。ビルトインすることで、大きく２つのメリットがあります。

・全てのワークロードのトラフィックを抜け漏れなく、簡単に分析
・大きなコストをかけずに、システム内の脅威拡散といった内部行為を検知、防止を実現

NSX 分散IDS/IPSの特徴 

NSX 分散IDS/IPS は、ハイパーバイザーの中で 仮想NIC部分で トランスペアレントの形でトラフィック検査(ステートフルインスペクション)を行います。NSX 分散IDS/IPS が 仮想NIC部分で トランスペアレントで動作できるため、これまでアプライアンスへのリダイレクトなどのヘアピン通信やそうしたトラフィック制御の特殊な設定を排除でき、ネットワークトポロジーから IDS/IPSアプライアンスも排除できますので、結果としてネットワーク設計がシンプルになります。

また、従来の IDS/IPS アプライアンスではハードウェア障害を考慮して、Active/Standby の冗長構成を別途設計で検討する必要があります。従来型アプライアンスを冗長化するためには、クライスター技術を理解したり、またはスパニングツリーを別途設計しないといけません。分散 IDS/IPS は、ハイパーバイザーの中で 仮想NIC部分で トランスペアレントの形でパケットの検査を行いますので、従来型の IDS/IPS アプライアンスのような障害点はなく冗長構成を別途設計必要性もありませんので、構成がとてもシンプルです。

NSX 分散IDS/IPS の検査処理には、保護対象のワークロードが稼働しているハイパーバイザーの余剰キャパシティ( CPU とメモリ)が活用されるので、新しいワークロードの追加に合わせて処理性能はリニアに拡張ができ、データセンターのトラフィック検査に十分なキャパシティを確保できるようになります。単純にESXiホストを増やしていくだけで、システム全体で 数百Gbps、数Tbps  の IDS/IPS 処理性能を提供することも可能になります。

これまで NSX に実装さた 分散ファイアウォール ももちろんこれと同じ処理性能のメリットを持っていますので、システム全体で 数百Gbps、数Tbps の ステートフルファイアウォールの 処理性能を提供することも可能です。

NSX 分散IDS/IPS は、ハイパーバイザーの中で 仮想 NIC 部分で動作するので、ワークロードが日々変化（追加や削除、vMotion）しても、常にセキュリティの設定やセキュリティポリシー、そしてセッション情報までが追従されるため、トラフィック検査の盲点を常に排除できるようになります。そのため、NSX 分散IDS/IPS のアプローチを採用することで、運用担当者はネットワーク構成といったインフラの制約をうけることなく、IDS/IPS 機能をワークロードレベルに きめ細かく適用することが可能になります。

NSX 分散IDS/IPS の特徴やメリットをご紹介しました。次回はユースケースなど、NSX 分散IDS/IPS の実態をさらに深堀する内容をご紹介していきたいと思います。

〜お知らせ〜

 ※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 でネットワークからエンドポイントまで包括的にセキュリティ対策を実現するには？そんな説明を聞いたみたい！という方はこちら
  → 新時代におけるゼロトラストセキュリティ【オンライン開催】 

 ※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 NSX 分散IDS/IPS でできる 新しい脅威への対策 appeared first on VMware Japan Blog.

みなさまこんにちは。 VMware Educationチームです。

VMware Educationチームでは、お一人で複数のトレーニングを受講いただく方に感謝の
意を込めて、2021年1月末までご受講費用が最大30% offとなるおトクなキャンペーンを
実施いたします。

キャンペーンのプランは2種類、プランAは2020年2月以降、既にトレーニング受講済みの
方も追加受講がおトクになるプランです。

[プランA]
同一受講者様 複数コース受講 & 分割発注
ご受講費用：30% off

[プランB]
同一受講者様 複数コース受講 & 一括発注
ご受講費用：期間中2、コース受講で20% off / 期間中3、コース受講で30% off

★ キャンペーン詳細はこちら をご参照ください。

VMware Educationサービスでは、多くのトレーニングコースでFace to Faceを避け、
オンラインで安心してご受講いただけるようコースをプランしております。

新しい製品、新しいバージョン対応のコースも多くリリースされております。

多くのみなさまのご受講をお待ちしております！

The post 2020年下半期限定！VMware Educationおまとめ受講キャンペーン appeared first on VMware Japan Blog.

こんにちは VMware TAM の松田です。

VMware TAM (Technical Account Manager) サービスでは、VMware 製品を利用いただいている多くのお客様の運用支援させていただいています。

VMware TAM サービスを利用しているお客様だけでなく、実際に VMware 製品を利用して運用されている多くのお客様にとって、有益な情報を発信する場としてブログを始めることになりました。

まず初回としては、VMware TAM LAB のご紹介です。

現在、Youtube 上に VMware TAM LAB チャネルが公開されており、毎週動画が公開されています。
全ての動画が英語となっていますが、製品の操作等については動画をみながら確認ができますので、製品の利用方法や画面遷移などについて確認したい場合にご利用いただければと思います。

なお、最近の投稿では vCenter STS 証明書の期限切れ前の更新について投稿が行われています。

本動画では、VMware {code}  で公開されているスクリプトを利用して複数の vCenter から STS 証明書の有効期限を簡単に取得する方法を紹介しています。 (動画 10:00 ～)

VMware {code} : Get-STSCerts.ps1

STS 証明書に関しては VMware KB (Knowledge Base) で関連情報が公開されていますので、以下の情報もご参照ください。(※ 最新の情報を確認したい場合は英語版を参照してください)

// STS 証明書の期限切れ有無の確認
* Checking Expiration of STS Certificate on vCenter Server (79248)  
https://kb.vmware.com/kb/79248  [英語版]
https://kb.vmware.com/s/article/79248?lang=ja [日本語版]

// (STS 証明書の期限が切れている場合) STS 証明書の更新
* “Signing certificate is not valid” – Regenerating and replacing expired STS certificate using PowerShell script on vCenter Server 6.5/6.7 installed on Windows (79263)
https://kb.vmware.com/kb/79263  [英語版]
https://kb.vmware.com/s/article/79263?lang=ja [日本語版]

* “Signing certificate is not valid” – Regenerating and replacing expired STS certificate using shell script on vCenter Server Appliance 6.5/6.7 (76719)
https://kb.vmware.com/s/article/76719  [英語版]
https://kb.vmware.com/s/article/76719?lang=ja [日本語版]

The post VMware TAM LAB のご紹介 (STS 証明書について) appeared first on VMware Japan Blog.

皆様こんにちは！

株式会社ネットワールドの Dell EMC 製品担当です。

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

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

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

＜アジェンダ＞

• 検証環境

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

[ハードウェア構成]

モデル：Hybrid

キャッシュ：SSD

ネットワーク：10GbE

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

[ハードウェア構成]
モデル：All Flash
キャッシュ：Intel Optane
ネットワーク：10GbE

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

[ハードウェア構成]
モデル：All Flash
キャッシュ：Intel Optane
ネットワーク：25GbE

検証環境

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

◆ VxRail

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

◆ ToR スイッチ

Dell PowerSwitch S5212-F を 2 台を Virtula 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 のクラスタ上に HCI Bench をデプロイし、ベンチマークを測定してみました。

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

今回、これから 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 VMware Japan Blog.

皆様こんにちは！

株式会社ネットワールドの Dell EMC 製品担当です。

前回に続いて、連載5回目は「VxRail  Intel® Optane SSD をキャッシュドライブで利用するとどれくらい性能が出るのか？」の検証結果の続きに関してご報告したいと思います！！

＜アジェンダ＞

• 検証環境

• パフォーマンス検証結果① -> 前回の Blog で実施済み!!

[ハードウェア構成]

モデル：Hybrid

キャッシュ：SSD

ネットワーク：10GbE、ノーマルフレーム

•  パフォーマンス検証結果② -> 前回の Blog で実施済み!!

[ハードウェア構成]
モデル：All Flash
キャッシュ：Intel Optane
ネットワーク：10GbE

•  パフォーマンス検証結果③ -> 今回はここから!!

[ハードウェア構成]
モデル：All Flash
キャッシュ：Intel Optane
ネットワーク：25GbE

なお、VxRail はVMware  vSphere にストレージ機能 VMware vSAN 機能を標準搭載した VMware 社とデル・テクノロジーズ社が共同開発した HCI になります。VxRail の基本的な事や運用管理面に関して疑問をお持ちの方はぜひ、以前のブログをご参照下さい。

そして最後には、キャッシュを Intel® Optane SSD に変更するとどれだけ価格が変わってくるのか？など、実際に検討するには気になってしまうポイントにも触れますので、ぜひ最後までご覧いただければと思います。

では、早速前回の続きですが、前回は、VxRail Intel® Optane SSD でパフォーマンス検証をしてみたところ、どうやら、10G ネットワークの帯域がボトルネックとなっている模様です。では、リンクスピードを25Gに変更して同じワークロードを流してみましょう。

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

◆IOPS  (参考値)
10G ネットワークと 25G ネットワークで比較した事、IOPS 値で Read 性能として、14 % の性能向上 / Write 性能として、8% の IOPS 性能の向上が本検証結果から確認できました。
ベースラインの Hybird 構成と比較すると、Read 性能として、5.21 倍 / Write 性能として、5.27 倍の IOPS 性能が出ている事が本検証では確認することができました。

◆スループット (参考値)
こちらも 10G ネットワークと 25G ネットワークで比較した事、こちらもスループットとしては、Read 性能として 5% / Write 性能として 8% のスループット向上が本検証では確認できました。
ベースラインの Hybird 構成と比較すると、Read 性能として 5 倍 / Write 性能として 5.23 倍のスループット性能が出ている事が本検証では確認することができました。

◆遅延(参考値)

こちらも 10G ネットワークと 25G ネットワークで比較した事、Read 発生時の遅延として 34% / Write 発生時に 15% の遅延を抑えられていることが確認出来ました。
また、ベースライン (Hybrid構成) と比較すると Read 発生時には、ベースラインの 20% 程度 / Write 発生時には、ベースラインの 33% 程度の遅延に遅延を抑えられている事を確認しました。

④ All-Flash Optane キャッシュ (25GbEジャンボフレーム) でのパフォーマンス

ちなみに、VxRail はノーマルフレーム (MTU=1500) でデプロイされますが、ジャンボフレームをサポートしています。
VMWare 社としても、ジャンボフレームが使用できる環境であれば使用を検討するように推奨事項として記載されているので、ジャンボフレームにしてベンチマークを測定してみます。

参考：vSAN Design and Sizing Guide (P.24)
http://www.vmware.com/files/pdf/products/vsan/VSAN_Design_and_Sizing_Guide.pdf

ちなみに、MTU の設定変更となると、すべてのノードの VMkernel を変更する必要があるので、かなり手間がかかりますよね？
VxRail の設定変更手順を確認してみると、今回検証に使ったバージョンでは MTU 変更ツールが配布されています。
Powershell で引数を指定してスクリプトを実行するだけなので、とても簡単にフレームサイズの変更ができました。

※ VxRail 側の設定変更前に、対向スイッチのフレームサイズ変更を実施する必要があります。
無事フレームサイズを MTU = 9000 に変更できたので、早速ベンチマークを測定してみます。

◆IOPS (参考値)
25G ネットワークを利用したデフォルト設定 (MTU:1500) と比較して、ジャンボフレームを利用した場合、Read 発生時に、4% 程度 / Write 発生時に、11% 程度のパフォーマンス向上が確認できました。

◆スループット (参考値)
25G ネットワークを利用したデフォルト設定 (MTU:1500) と比較して、ジャンボフレームを利用した場合、Read/Write 発生時ともに 11% の性能向上を確認することが出来ました。
また、ベースラインの Hybird 構成と比較した場合、Read 発生時に 5.55 倍 / Write 発生時に 5.82 倍のスループット性能の向上を確認することが出来ました。

◆遅延 (参考値)
25G ネットワークを利用したデフォルト設定 (MTU:1500) と比較して、ジャンボフレームを利用した場合、Write 発生時に 17% の遅延を抑える事を確認できました。また、ベースライン (Hybrid 構成) と比較した場合、Read 発生時には 20% 程度、Write 発生時には 27% の遅延に抑えていることを確認できました。

⑤ VxRail 7.0 All-Flash Optaneキャッシュ(25GbE)でのパフォーマンス

2020 年 4 月に vSphere7.0 がバンドルされた VxRail 7.0 がリリースされました。
当然、vSAN も 7.0 にアップデートされています。ということで、早速アップデートしてみたいと思います。

VxRail アップデート ①

vCenter にアクセスして、vCenter Plug-in からアップグレード開始

VxRail アップデート ②

ファイルをアップロードして、そのままアップグレードを進めます。

VxRail アップデート ③

vCenter7 の仕様変更に対応する為、テンポラリ IP を指定して、そのままアップグレード作業を続行

VxRail アップデート ④

ウィザードを進めているともうアップデート作業は完了。サービスへの影響も無いし、本当に簡単でした。

⑤vSphere7 へのアップグレードした場合でのパフォーマンス

◆IOPS (参考値)

ESXi6.7U3 と比較して、ESXi7.0 では、Read 発生時には 19% / Write 発生時には 11% のパフォーマンス向上が確認できました。ESXi7.0 へアップグレードの前後 (同一ハードウェア) でパフォーマンスを取得・比較しているため、ESXi7.0 ではやはり、パフォーマンスも更に向上している事が確認できました。

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

ESXi6.7U3 と比較して、ESXi7.0 では Read 発生時には 15% / Write 発生時には 11% のパフォーマンス向上が確認できました。こちらも、ESXi7.0 ではやはり、パフォーマンスも更に向上している事が確認できる結果となりました。

◆遅延 (参考値)

Read発生時で 20% / Write 発生時に 28% の遅延を抑えることが出来ました。こちらも ESXi7.0 へアップグレードすることにより、ハードウェアをより効率的に活用できることがわかる結果となりました。

⑥ FTT=0 の場合のパフォーマンス (参考)

VxRail デフォルトの SPBM では、FTT=1,Mirroring となっているので、同じデータを二つのキャッシュデバイスに書き込みする挙動となります。となると、単純に IOPS で計算すると値は半分になってしまいます。その為、試しに FTT=0 の SPBM を作成してベンチマークを測定してみましょう (本番環境では行わないでください。あくまでも検証作業の範囲内で実施しております)。
結果、Write の IOPS として約 50 万 IOPS を達成しました。
P4800X の公称値が Write で 50 万 IOPS なので、ハードウェアスペックの公称値を達成することができた事となります。

◆ボトルネックの有無

vRealize Operations や esxtop、vsantop コマンド等で、CPU / メモリ / ネットワーク / キャッシュディスクといった各コンポーネントのリソース状況を確認してみましたが、ボトルネックとなる部分は特に見られませんでした。すなわち、VxRail は非常にバランスが取れているハードウェア構成を実現しているという事が確認できました。

なお、esxtop コマンドは ESXi 上に昔から存在しているコマンドラインツールですが、vsantop コマンドは vSAN6.7U3 から追加になっている vSAN パフォーマンス調査用のコマンドラインツールになります。もし、ご存じない方はぜひ、一度、ご活用頂ければと思います。

◆本検証での結論

・ハードウェアスペックの公称値を達成する様なパフォーマンスが確認できた。

P4800X の公称値で Random Write = 50 万 IOPS なので、オーバーヘッド等も考慮すると VxRail で性能を十分に発揮できると考えられる。

・Hybrid モデルと比較し、6 倍近いパフォーマンス差が測定された。

但し、CPU,メモリ等の構成が異なるため、Intel® Optane SSD をキャッシュ層として利用するだけで 6 倍の性能向上が見込めるとまでは一概には言えません。あくまでも一つの検証結果という事で参考としてご利用下さい。
なお、”6 倍のパフォーマンス結果出た” というと、Hybird 構成が遅く感じてしまうかもしれませんが、Hybrid 構成でも一般的な仮想環境では必要十分なパフォーマンスを計測しております (むしろ、既存の 3Tier 構成等と比べても十分、高速なパフォーマンスを計測しております!!) 。具体的なパフォーマンス結果が気になる方はネットワールド担当営業までご連絡ください。

・Intel® Optane SSD 構成で VxRail(vSAN) を組む場合、25G /100G ネットワーク等の選択も必要に応じて検討する必要がある。

Intel® Optane SSD のパフォーマンスを最大限発揮するためには、vSAN ネットワークを今までの様に 10G ネットワークだけでは無くて、25G / 100G ネットワークの構築も検討する必要がある (これは VxRail に限らず、他社製品も含めて HCI という製品と上手に付き合うための構成における重要なポイント)。そうしないと、今後、どんどん出てくるであろう Intel® Optane SSD の様な高速なディスクを利用して、スケールアウト構成を組んでいく際にネットワーク側がボトルネックになり得るので、初期からそこまで考慮して設計することが大切。また、ジャンボフレームなどの採用も追加費用が発生する作業ではない為、構築時にはぜひ、検討して頂きたいポイントです。

・非常に高いパフォーマンスが要求されるアプリケーションも十分に VxRail で稼働させられることが確認できた

高い IOPS / スループットを計測する一方で、かなりの低い遅延を実現しているため、高いパフォーマンスを要求される様なアプリケーションでも十分、稼働させることができると考えられる。その為、今までは少し躊躇してしまう様なデータベースや基幹業務で利用するアプリケーション等もハイパフォーマンス・低遅延で実行できる環境が VxRail で実現可能なことが確認できました。
(また、メジャーバージョンアップというと非常に多くの準備が必要になる作業だと思いますが、メジャーバージョンアップ等も非常に簡単に無停止で行える所も VxRail の良さですね!!)

・VxRail は全てのハードウェアコンポーネントがバランスよく選択されていることを確認

高い IOPS / スループットを計測した中で、明確なボトルネックとなっているコンポーネントを特定することはできなかった。採用されている各ハードウェアコンポーネントがバランス良く配置されており、コンポーネントレベルでのサチレーションが発生していない事も確認することができた(ディスク 1 本ずつの遅延を計測する様なツール類も充実しており、仮に何か問題が発生した時にも充実した運用管理ツールがあることも確認できた)。

◆本ブログでのまとめ

VxRail に Intel® Optane SSD を搭載することにより、パフォーマンスの向上が可能ということがおわかり頂けたかと思います。
では実際価格はどうなのか？性能が良いので当然高いんでしょう？と思ってらっしゃる方もいると思いますので、実際に価格試算をしてみました。

キャッシュディスク以外は全て同じスペックにしています。

【SSD構成】

 
【Intel® Optane SSD 構成】

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

 
価格差はどれくらいになるかというと・・・

定価ベースで SSD 構成と比べて Intel® Optane SSD 構成の方が約 1.1 倍となりました！
※2020 年 7 月現在

性能差 (パフォーマンスは、6倍近くのパフォーマンスが発揮するかも!?) を考慮すると、かなりお得に導入が出来ますね！
もちろん、ネットワールドでは今回の検証した内容で比較をしたいので両方の見積りをください！というご要望も喜んで対応させて頂きます!! 複数構成のパターンでもご遠慮なくご依頼頂ければと思います。
また Intel® Optane SSD の性能を引き出すチューニングのご相談から構築まで、VxRail 担当エンジニアが対応させて頂きますので、VxRail の構築作業もぜひ併せてネットワールドにお任せください！

それではここで全 5 回の連載が終了となります。最後まで読んでいただきありがとうございました。ブログを通して VxRail が良さが伝わり、選択肢の一つになっていただければ幸いです！！

ネットワールドはこれからも蓄積してきた技術的ノウハウを活かして、さまざまな情報配信を行ってまいります。

今後もVxRailの最新情報を得たい方は、ぜひネットワールドのVxRailチャンピオンクラブにご参加ください！
https://www.networld.co.jp/product/emc/emcvxrail_championsclub/

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

みなさま、こんにちは。VMwareの児島です。先日開催された「Digital Workspace Day – LIVE ～事業継続対策として有効なテレワークを実現するには？」のセッション紹介記事第三弾です。私が担当しました「VPN に依存しない、テレワーク時代を見据えたアプリケーションアクセス〜ゼロトラストセキュリティ」をダイジェスト版としてご紹介いたします。
より詳細な内容を知りたいと思っていただけた方は「EVOLVE ONLINE」（記事下部にログインリンク掲載）にご登録・ログインいただくことで、当日の収録動画および資料がダウンロードが可能です。是非、アクセスのほどよろしくお願いいたします。
 

「これからの時代に必要な事業継続のカギは」

緊急事態宣言が発令されたことにより、多くのみなさまが今までとは違う働き方への実現に取り組まれたかと思います。しかし、前例のないこの状況下においては手探りで事業継続対策をされた方も多いのではないでしょうか。本セッションではこの状況下で発生しうる下記のような課題に触れ、利便性低下やセキュリティ懸念と言った課題に対してどのようなアプローチが有効なのか、事業継続に必要なポイントについて整理しお話をさせていただきました。

• 物理的な課題
  -社給デバイスを持ち帰れない。（業務ポリシー上で禁止であったり、端末がデスクトップ型であるなど）
  -社員全員分の在宅勤務用パソコンが無い（一部の利用者にしか配布していないなど）
• 業務アプリに対する課題
  -VPN接続が不安定
  -普段利用している業務アプリが社外から利用できない（業務ポリシー上禁止であったり、ネットワーク負荷により）
• セキュリティに関する課題
  -前例がない状況下のため、漠然とした不安がある。

図1:テレワーク実施時に直面した課題

 
また当日は参加者の皆様にオンラインアンケートを実施せていただき、リアルなご意見を頂戴いたしました。こちらの結果もEVOLVE ONLINEに掲載されておりますので是非ご確認ください。
 
 

「ゼロトラストセキュリティって？」

最近よくITセキュリティの分野で耳にすることが多い「ゼロトラストセキュリティ」。復習も兼ねた概要のご説明に加えて従来の境界型セキュリティモデルとの比較や、この状況下においてゼロトラストセキュリティモデルがどのように有効なのかをセッションではご紹介しています。

図2:ゼロトラストセキュリティとは

「Workspace ONEで実現するゼロトラストセキュリティなテレワーク環境とは？！」

当日のセッションではVMwareが考えるゼロトラストセキュリティモデルと、VMware Horizonも含めたVMware Workspace ONE （以下、Workspace ONE） プラットフォームの各製品がそれぞれどのような役目を担うのか、またどのようにゼロトラストセキュリティを実現していくのかユースケースと共にご紹介いたしました。

図3:ゼロトラスト5つの柱と可視化/分析、自動化

図4:Workspace ONEによるゼロトラストセキュリティモデルのアプリケーションアクセス

 
テレワーク環境下における業務継続やゼロトラストセキュリティの実現ににご興味がある方は、是非「EVOLVE ONLINE」にご登録・ログインいただき、当日の収録動画および資料を参照していただけますと幸いです。また、「EVOLVE ONLINE」では、EUC のソリューションだけでなく、その他様々なコンテンツを提供しております。お客様の抱えられている課題に対する解決策がきっと見つかると思います。
———-
【講演資料について】
下記の URL より EVOLVE ONLINE にご登録いただき、マイページより資料・動画をご確認いただけますので、是非、ご活用ください。
EVOLVE ONLINE
EVOLVE ONLINE ご登録＞マイページ＞「ウェビナーを視聴する」メニュー
———-
最後まで、読んで頂きましてまことにありがとうございました。

The post テレワークを実施してみたけれども・・・リアルなお悩みとは？!　Workspace ONEで本当に必要なテレワーク環境を実現 appeared first on VMware Japan Blog.

みなさまこんにちは。 VMware Educationチームです。

例年2月に開催しておりました『VMware Education Partner Day』ですが、2020年は
企画段階で世の中が在宅勤務にシフトし、一堂に会することが難しい状況となりました。

ビジネスセッション、Award Partyを含むPartner Dayの場で贈呈させていただきたかった
Partner Awardですが、本年はトロフィーを対象の皆さま方に送付させていただき、Blogにて
ご紹介させていただくことといたしました。

以下のパートナー様、VMware Certified Instructorの皆さま方に、2019年のVMware Education
ビジネスに特にご貢献いただいた感謝を込めて、Awardを贈呈させていただきます。

《VMware Education Partner of the Year 2019》
CTC テクノロジー株式会社 様

《VMware Education Partner Award 2019》
株式会社富士通ラーニングメディア 様

《VMware Certified Instructor Award 2019》
(氏名50音順)

千田 泰史 様 (日本サード・パーティ株式会社)

二岡 祐介 様

間所 徹雄 様 (日本ヒューレット・パッカード株式会社)

盛  洋史 様 (CTCテクノロジー株式会社)

受賞されたVCIの皆さま、パートナー様のみならず、VMware Education サービスに関わる
全ての皆さまに感謝申し上げます。

今後とも、VMware ならびにVMware Educationサービスのビジネスの発展へのご協力を
よろしくお願い申し上げます。

The post VMware Education Partner Award 2019 appeared first on VMware Japan Blog.

皆様こんにちは！

株式会社ネットワールドの Dell EMC 製品担当です。

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

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

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

＜アジェンダ＞

• 検証環境

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

[ハードウェア構成]

モデル：Hybrid

キャッシュ：SSD

ネットワーク：10GbE

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

[ハードウェア構成]
モデル：All Flash
キャッシュ：Intel Optane
ネットワーク：10GbE

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

[ハードウェア構成]
モデル：All Flash
キャッシュ：Intel Optane
ネットワーク：25GbE

検証環境

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

◆ VxRail

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

◆ ToR スイッチ

Dell PowerSwitch S5212-F を 2 台を Virtula 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 のクラスタ上に HCI Bench をデプロイし、ベンチマークを測定してみました。

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

今回、これから 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 VMware Japan Blog.

皆様こんにちは！

株式会社ネットワールドの Dell EMC 製品担当です。

前回に続いて、連載5回目は「VxRail  Intel® Optane SSD をキャッシュドライブで利用するとどれくらい性能が出るのか？」の検証結果の続きに関してご報告したいと思います！！

＜アジェンダ＞

• 検証環境

• パフォーマンス検証結果① -> 前回の Blog で実施済み!!

[ハードウェア構成]

モデル：Hybrid

キャッシュ：SSD

ネットワーク：10GbE、ノーマルフレーム

•  パフォーマンス検証結果② -> 前回の Blog で実施済み!!

[ハードウェア構成]
モデル：All Flash
キャッシュ：Intel Optane
ネットワーク：10GbE

•  パフォーマンス検証結果③ -> 今回はここから!!

[ハードウェア構成]
モデル：All Flash
キャッシュ：Intel Optane
ネットワーク：25GbE

なお、VxRail はVMware  vSphere にストレージ機能 VMware vSAN 機能を標準搭載した VMware 社とデル・テクノロジーズ社が共同開発した HCI になります。VxRail の基本的な事や運用管理面に関して疑問をお持ちの方はぜひ、以前のブログをご参照下さい。

そして最後には、キャッシュを Intel® Optane SSD に変更するとどれだけ価格が変わってくるのか？など、実際に検討するには気になってしまうポイントにも触れますので、ぜひ最後までご覧いただければと思います。

では、早速前回の続きですが、前回は、VxRail Intel® Optane SSD でパフォーマンス検証をしてみたところ、どうやら、10G ネットワークの帯域がボトルネックとなっている模様です。では、リンクスピードを25Gに変更して同じワークロードを流してみましょう。

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

◆IOPS  (参考値)
10G ネットワークと 25G ネットワークで比較した事、IOPS 値で Read 性能として、14 % の性能向上 / Write 性能として、8% の IOPS 性能の向上が本検証結果から確認できました。
ベースラインの Hybird 構成と比較すると、Read 性能として、5.21 倍 / Write 性能として、5.27 倍の IOPS 性能が出ている事が本検証では確認することができました。

◆スループット (参考値)
こちらも 10G ネットワークと 25G ネットワークで比較した事、こちらもスループットとしては、Read 性能として 5% / Write 性能として 8% のスループット向上が本検証では確認できました。
ベースラインの Hybird 構成と比較すると、Read 性能として 5 倍 / Write 性能として 5.23 倍のスループット性能が出ている事が本検証では確認することができました。

◆遅延(参考値)

こちらも 10G ネットワークと 25G ネットワークで比較した事、Read 発生時の遅延として 34% / Write 発生時に 15% の遅延を抑えられていることが確認出来ました。
また、ベースライン (Hybrid構成) と比較すると Read 発生時には、ベースラインの 20% 程度 / Write 発生時には、ベースラインの 33% 程度の遅延に遅延を抑えられている事を確認しました。

④ All-Flash Optane キャッシュ (25GbEジャンボフレーム) でのパフォーマンス

ちなみに、VxRail はノーマルフレーム (MTU=1500) でデプロイされますが、ジャンボフレームをサポートしています。
VMWare 社としても、ジャンボフレームが使用できる環境であれば使用を検討するように推奨事項として記載されているので、ジャンボフレームにしてベンチマークを測定してみます。

参考：vSAN Design and Sizing Guide (P.24)
http://www.vmware.com/files/pdf/products/vsan/VSAN_Design_and_Sizing_Guide.pdf

ちなみに、MTU の設定変更となると、すべてのノードの VMkernel を変更する必要があるので、かなり手間がかかりますよね？
VxRail の設定変更手順を確認してみると、今回検証に使ったバージョンでは MTU 変更ツールが配布されています。
Powershell で引数を指定してスクリプトを実行するだけなので、とても簡単にフレームサイズの変更ができました。

※ VxRail 側の設定変更前に、対向スイッチのフレームサイズ変更を実施する必要があります。
無事フレームサイズを MTU = 9000 に変更できたので、早速ベンチマークを測定してみます。

◆IOPS (参考値)
25G ネットワークを利用したデフォルト設定 (MTU:1500) と比較して、ジャンボフレームを利用した場合、Read 発生時に、4% 程度 / Write 発生時に、11% 程度のパフォーマンス向上が確認できました。

◆スループット (参考値)
25G ネットワークを利用したデフォルト設定 (MTU:1500) と比較して、ジャンボフレームを利用した場合、Read/Write 発生時ともに 11% の性能向上を確認することが出来ました。
また、ベースラインの Hybird 構成と比較した場合、Read 発生時に 5.55 倍 / Write 発生時に 5.82 倍のスループット性能の向上を確認することが出来ました。

◆遅延 (参考値)
25G ネットワークを利用したデフォルト設定 (MTU:1500) と比較して、ジャンボフレームを利用した場合、Write 発生時に 17% の遅延を抑える事を確認できました。また、ベースライン (Hybrid 構成) と比較した場合、Read 発生時には 20% 程度、Write 発生時には 27% の遅延に抑えていることを確認できました。

⑤ VxRail 7.0 All-Flash Optaneキャッシュ(25GbE)でのパフォーマンス

2020 年 4 月に vSphere7.0 がバンドルされた VxRail 7.0 がリリースされました。
当然、vSAN も 7.0 にアップデートされています。ということで、早速アップデートしてみたいと思います。

VxRail アップデート ①

vCenter にアクセスして、vCenter Plug-in からアップグレード開始

VxRail アップデート ②

ファイルをアップロードして、そのままアップグレードを進めます。

VxRail アップデート ③

vCenter7 の仕様変更に対応する為、テンポラリ IP を指定して、そのままアップグレード作業を続行

VxRail アップデート ④

ウィザードを進めているともうアップデート作業は完了。サービスへの影響も無いし、本当に簡単でした。

⑤vSphere7 へのアップグレードした場合でのパフォーマンス

◆IOPS (参考値)

ESXi6.7U3 と比較して、ESXi7.0 では、Read 発生時には 19% / Write 発生時には 11% のパフォーマンス向上が確認できました。ESXi7.0 へアップグレードの前後 (同一ハードウェア) でパフォーマンスを取得・比較しているため、ESXi7.0 ではやはり、パフォーマンスも更に向上している事が確認できました。

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

ESXi6.7U3 と比較して、ESXi7.0 では Read 発生時には 15% / Write 発生時には 11% のパフォーマンス向上が確認できました。こちらも、ESXi7.0 ではやはり、パフォーマンスも更に向上している事が確認できる結果となりました。

◆遅延 (参考値)

Read発生時で 20% / Write 発生時に 28% の遅延を抑えることが出来ました。こちらも ESXi7.0 へアップグレードすることにより、ハードウェアをより効率的に活用できることがわかる結果となりました。

⑥ FTT=0 の場合のパフォーマンス (参考)

VxRail デフォルトの SPBM では、FTT=1,Mirroring となっているので、同じデータを二つのキャッシュデバイスに書き込みする挙動となります。となると、単純に IOPS で計算すると値は半分になってしまいます。その為、試しに FTT=0 の SPBM を作成してベンチマークを測定してみましょう (本番環境では行わないでください。あくまでも検証作業の範囲内で実施しております)。
結果、Write の IOPS として約 50 万 IOPS を達成しました。
P4800X の公称値が Write で 50 万 IOPS なので、ハードウェアスペックの公称値を達成することができた事となります。

◆ボトルネックの有無

vRealize Operations や esxtop、vsantop コマンド等で、CPU / メモリ / ネットワーク / キャッシュディスクといった各コンポーネントのリソース状況を確認してみましたが、ボトルネックとなる部分は特に見られませんでした。すなわち、VxRail は非常にバランスが取れているハードウェア構成を実現しているという事が確認できました。

なお、esxtop コマンドは ESXi 上に昔から存在しているコマンドラインツールですが、vsantop コマンドは vSAN6.7U3 から追加になっている vSAN パフォーマンス調査用のコマンドラインツールになります。もし、ご存じない方はぜひ、一度、ご活用頂ければと思います。

◆本検証での結論

・ハードウェアスペックの公称値を達成する様なパフォーマンスが確認できた。

P4800X の公称値で Random Write = 50 万 IOPS なので、オーバーヘッド等も考慮すると VxRail で性能を十分に発揮できると考えられる。

・Hybrid モデルと比較し、6 倍近いパフォーマンス差が測定された。

但し、CPU,メモリ等の構成が異なるため、Intel® Optane SSD をキャッシュ層として利用するだけで 6 倍の性能向上が見込めるとまでは一概には言えません。あくまでも一つの検証結果という事で参考としてご利用下さい。
なお、”6 倍のパフォーマンス結果出た” というと、Hybird 構成が遅く感じてしまうかもしれませんが、Hybrid 構成でも一般的な仮想環境では必要十分なパフォーマンスを計測しております (むしろ、既存の 3Tier 構成等と比べても十分、高速なパフォーマンスを計測しております!!) 。具体的なパフォーマンス結果が気になる方はネットワールド担当営業までご連絡ください。

・Intel® Optane SSD 構成で VxRail(vSAN) を組む場合、25G /100G ネットワーク等の選択も必要に応じて検討する必要がある。

Intel® Optane SSD のパフォーマンスを最大限発揮するためには、vSAN ネットワークを今までの様に 10G ネットワークだけでは無くて、25G / 100G ネットワークの構築も検討する必要がある (これは VxRail に限らず、他社製品も含めて HCI という製品と上手に付き合うための構成における重要なポイント)。そうしないと、今後、どんどん出てくるであろう Intel® Optane SSD の様な高速なディスクを利用して、スケールアウト構成を組んでいく際にネットワーク側がボトルネックになり得るので、初期からそこまで考慮して設計することが大切。また、ジャンボフレームなどの採用も追加費用が発生する作業ではない為、構築時にはぜひ、検討して頂きたいポイントです。

・非常に高いパフォーマンスが要求されるアプリケーションも十分に VxRail で稼働させられることが確認できた

高い IOPS / スループットを計測する一方で、かなりの低い遅延を実現しているため、高いパフォーマンスを要求される様なアプリケーションでも十分、稼働させることができると考えられる。その為、今までは少し躊躇してしまう様なデータベースや基幹業務で利用するアプリケーション等もハイパフォーマンス・低遅延で実行できる環境が VxRail で実現可能なことが確認できました。
(また、メジャーバージョンアップというと非常に多くの準備が必要になる作業だと思いますが、メジャーバージョンアップ等も非常に簡単に無停止で行える所も VxRail の良さですね!!)

・VxRail は全てのハードウェアコンポーネントがバランスよく選択されていることを確認

高い IOPS / スループットを計測した中で、明確なボトルネックとなっているコンポーネントを特定することはできなかった。採用されている各ハードウェアコンポーネントがバランス良く配置されており、コンポーネントレベルでのサチレーションが発生していない事も確認することができた(ディスク 1 本ずつの遅延を計測する様なツール類も充実しており、仮に何か問題が発生した時にも充実した運用管理ツールがあることも確認できた)。

◆本ブログでのまとめ

VxRail に Intel® Optane SSD を搭載することにより、パフォーマンスの向上が可能ということがおわかり頂けたかと思います。
では実際価格はどうなのか？性能が良いので当然高いんでしょう？と思ってらっしゃる方もいると思いますので、実際に価格試算をしてみました。

キャッシュディスク以外は全て同じスペックにしています。

【SSD構成】

 
【Intel® Optane SSD 構成】

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

 
価格差はどれくらいになるかというと・・・

定価ベースで SSD 構成と比べて Intel® Optane SSD 構成の方が約 1.1 倍となりました！
※2020 年 7 月現在

かなりお得に導入が出来ますね！

もちろん、ネットワールドでは今回の検証した内容で比較をしたいので両方の見積りをください！というご要望も喜んで対応させて頂きます!! 複数構成のパターンでもご遠慮なくご依頼頂ければと思います。
また Intel® Optane SSD の性能を引き出すチューニングのご相談から構築まで、VxRail 担当エンジニアが対応させて頂きますので、VxRail の構築作業もぜひ併せてネットワールドにお任せください！

それではここで全 5 回の連載が終了となります。最後まで読んでいただきありがとうございました。ブログを通して VxRail が良さが伝わり、選択肢の一つになっていただければ幸いです！！

ネットワールドはこれからも蓄積してきた技術的ノウハウを活かして、さまざまな情報配信を行ってまいります。

今後もVxRailの最新情報を得たい方は、ぜひネットワールドのVxRailチャンピオンクラブにご参加ください！
https://www.networld.co.jp/product/emc/emcvxrail_championsclub/

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

「あなたのサイトは、きちんと100％稼働していますか？」

Webサイトは、様々な個人や企業が情報発信のために作成されております。2020年7月時点には、約12億サイトが公開されているようです。(参考: https://news.netcraft.com/archives/2020/07/27/july-2020-web-server-survey.html )
この記事を読まれている方の中にもサイトを運用されている方はたくさんいらっしゃるのではないでしょうか？

そんな、みなさんに1つ質問です。「あなたのサイトは、きちんと100％稼働していますか？」

定常時に安定してサイトが表示されているのは、普通なことかもしれません。
しかし、テレビや他のサイト、SNS で紹介された際の急激なトラフィック需要が発生している際も問題ありませんでしょうか？
はたまた、Web サイトへの攻撃やインフラ側に障害が発生していても問題なく表示されてますか？

ここまであげると 100% 稼働していると言い切れないことが大半だと思いますので、それをどのように解決できるか、この記事でご紹介したいと思います。

一般的なWebシステムの構成 / 課題点

Webサイトは下記図のように構成されていることが一般的です。

図の中に書かれている “ADC” は アプリケーションデリバリーコントローラ と呼ばれる L4-7 ロードバランサに加えて、様々な機能が付与された機器となります。
基本的な負荷分散の機能だけでなく、セキュリティの機能やコンテンツキャッシュの機能を持っており、安定したサービスを提供する役割をになってます。

それでは、なぜ ADC を入れてもサービスが止まってしまうことがあるのでしょうか？
主に下記3つの課題があると考えられます。

• トラフィックが予想より多く来るなどリソース不足
• 通信がきちんと把握できていないアプリケーション側の問題
• 外部から攻撃で帯域の圧迫

3つのポイントにフォーカスして、あなたのサイトを安定させるための方法をこの記事では紹介いたします。

VMware NSX^® Advanced Load Balancer とは

この記事で紹介する NSX Advanced Load Balancer は、様々な特徴で従来の ADCと異なります。

主な違いは、下記5つの特徴です。

• 設定を行うコントローラ とデータ転送する サービスエンジン が分離していること
• サービスエンジン間で処理の負荷分散が可能なため、伸縮性を実現
• サービスエンジンは、仮想版だけでなく、物理サーバへのインストール、コンテナ版も提供
  • これによりパブリッククラウドを含めた、様々な環境での実行が可能
• 様々な環境への連携が実装されており、各種自動化可能
• 流れるトラフィックに関する情報の収集分析を実現

それでは、安定したサイトの実現にこれらの特徴がどのようにお手伝いできるかご紹介します。

リソース不足を解消！ 分散型アーキテクチャによる伸縮性

まず一つ目に紹介するのは、リソース不足を発生しにくくする分散型アーキテクチャです。従来型のロードバランサは、 Active / Standby な冗長構成が行われております。2台での冗長構成を行っていても、Standby 側の1台は障害が発生した際にしか稼働しません。また、Active 側もトラフィックの急増に耐えられるようにリソース確保が行われてるため、定常時には10〜20%程度しか使われないことが現状です。大規模環境では、このような Active / Standby 側構成がシステムや環境ごとに構築されております。そのような環境でどのような問題が考えられるでしょうか？

一つ目は、リソースを有効活用することができないことです。
複数システムのうち、1つのリソースだけでトラフィックが急増し、リソースが足りなくなりそうな時に何かできることはありますでしょうか？処理できる上限は、1台の ADC であることは変わらないので、リソースを増やすには、ハードウェアを交換したり、CPU / Memory を増やすことが必要となってしまいます。周りのハードウェアにリソースの余裕があったとしても、転用できません。

二つ目は、管理ポイントが多くなってしまうことです。
ADC は、Active / Standby のペア毎に、管理する必要があります。そのため、システム全体で利用する ADC の数が多くなればなるほど、管理ポイントが増えていきます。それにより、トラブルシュートやソフトウェアアップデートの際に必要な作業が多くなります。

これを解消するのが、 分散型アーキテクチャを利用している NSX Advanced Load Balancer です。

NSX Advanced Load Balancer では、データを転送するサービスエンジンには設定を行うことができません。全てコントローラで制御します。それによって、先ほど挙げた管理ポイントが多くならず、大規模な環境も管理することができます。アップグレードする際もワンクリックで全てをあげることが可能です。

また、このサービスエンジンは、様々な環境で動かすことができます。
VMware vSphere^® 基盤だけでなく、コンテナ環境や Linux サーバへの直接インストールすることが可能です。パブリッククラウド向けには、それぞれの環境動くバージョンを提供しております。AWS版 Azure版 はこちらからアクセス可能です。

様々な箇所で動かせるだけがサービスエンジンの特徴ではありません。最大の特徴は、複数のサービスエンジンで一つのサービス(仮想 IP )の処理を分散して行うことができることです。各サービス毎に 代表する サービスエンジンが自動で選択されます。しかし、着信したトラフィックは、他のサービスエンジン向けに 再転送を行い、処理自体を他のサービスエンジンに任せることが可能です。
下記、動画をご覧ください。

複数台でサービスを分散させて処理することができるため、簡単に Scale In / Scale Out させて、柔軟にキャパシティを変更させることができます。また、ARPを利用し代表のサービスエンジンをシームレスに動かすことができるため、ダウンタイムを無くしてアップグレードすることの実現にも役立っております。

リアルタイム分析で、アプリの通信状況の把握

従来、アプリケーションの遅延や問題を調べるには、専用のモニタリングツールを使うことが一般的でした。これらは、様々な箇所からの情報を利用することで、アプリケーションに関わる様々な情報を可視化することができます。しかし、実際に導入するには、対応している OS に専用のエージェントをインストールしたり、ライブラリを既存のアプリケーション内部に埋め込んだりすることが必要となり、導入するハードルが高くなっているのが現状です。

NSX Advanced Load Balancer では、サービスエンジンでトラフィックを処理するだけではなく、流れているトラフィックに関する情報を取得しております。取得された情報は、コントローラに転送されており、コントローラ上で可視化することができます。

実際の様子は下記動画をご覧ください。

従来のアプリケーション可視化手法では、様々な箇所にエージェントをインストールしたり、プログラムの回収が必要でしたが、アプリケーション通信が、 NSX Advanced Load Balancer を経由するだけでこれらの情報を取得することができます。

また、取得した情報を用いた検索も簡単に行えます。例えば下記のような検索ができます。

• レスポンスタイムが 特定時間以上かかっているもの
  • 原因が端末側なのか、サーバ側なのかなどをさらに深掘りすることが可能
• 特定のOSからのアクセス
• HTTP Status Code が 期待されていないもの
  • これにより、そもそも不正にアクセスされているのか
  • サイト内部でのリソースの指定が間違っているのか

これにより、正常に動いていると思われるウェブサイトも実アクセスを確認することで発生しうる問題を発見することが容易にできるようになります。

簡単に Web サイトを守る Intelligent WAF！

いくら正常な Web サイトであっても、外部に公開されている限り、攻撃の対象となります。 Web アプリケーションの脆弱性を攻撃することが行われておりますが、攻撃自体を防ぐ方法は複数の手法が考えられます。セキュリティパッチを当てたり、プログラム自体の修正を行うことで、脆弱性を塞ぐことができます。また、簡単に対応できないものもあるため、 WAF (Web Application Firewall) を入れて防ぐことが行われます。

しかし、WAF 自体に課題がないわけではありません。主に下のような課題があります。

• パフォーマンスに上限がある
• 可視化が不十分
• ルール設定が複雑なため、全てのルールを適用して負荷がかかる

NSX Advanced Load Balancer で WAF を行うと上記課題を簡単に解決できます。

まず、パフォーマンスは、この記事の前半でも取り上げた分散型アーキテクチャで解決することができます。通常の ADC と同様に通常の WAF のパフォーマンスの上限は 1台分のパフォーマンスとなりますが、 NSX Advanced Load Balancer は、複数で分散処理させることができるため、WAF を有効にしても必要なリソースを簡単に伸縮させることができます。

続いて、可視化の部分も先ほど述べてきました。複数に分散された サービスエンジンから情報を収集し、コントローラで可視化を実施いたします。セキュリティの可視化も同じように実施することができます。

最後にルール設定ですが、カテゴリーに分けられているため、それごとに有効 / 無効にすることが可能です。これにより必要最低限のルールを適用することが可能です。また、可視化の部分で実際のどのルールが適用され通信できなくなっているか。という情報も可視化することができるため、正常にできるはずの通信が落とされたとしても簡単に特定することができ、それも元に例外処理を簡単に適用することができます。このルールセット自体も、設定をすることで自動ダウンロードすることも可能です。

[まとめ] NSX Advanced Load Balancer で安定したサイトを実現

この記事では、安定した Web サイトの構築に必要なポイントとして、下記3つをあげました。

• トラフィックが予想より多く来るなどリソース不足
• 通信がきちんと把握できていないアプリケーション側の問題
• 外部から攻撃で帯域の圧迫

今までの Webシステムでは、 ADC、アプリケーション可視化ツール、WAF など様々なツールを利用することで安定するように構築されてきておりました。しかし、用途によって様々なツールがあると管理ポイントが増えて複雑になることが想定されます。

NSX Advanced Load Balancer では、今まであった様々なツールで解決していたものを、1つのソリューションだけで実現することができます。また一つのソリューションのため、管理自体も簡単に行うことができるのがポイントです。

もしご興味を持っていただけたならば、ぜひ下記リソースにもアクセスしてみてください。

• NSX Advanced Load Balancer 製品ページ
• Hands-on Labs (HOL)
  • こちらのサイトで、”NSX Advanced Load Balancer” で検索してみてください。
• IT 価値創造塾 NSX Advanced Load Balancer 紹介ページ

The post ハイブリッド時代の NSX Advanced Load Balancer の活用 appeared first on VMware Japan Blog.

みなさま、こんにちは。VMware の鈴木です。

今回は、2020年6月25日に公開された、“Workspace ONE Cloud Services Achieve ISO 27001, ISO 27017, and ISO 27018 Certifications” の抄訳をお届けいたします。


昨今、急速に企業や組織がテレワークへシフトしていく中、セキュアでコンプライアンスに準拠したテレワークのソリューションに対する需要が高まっています。一方で、VMware のお客様は、クラウドがホストするデータのセキュリティを損なうことなく、新しい働き方の課題に対応する必要があります。

VMwareは、コンプライアンス・ポートフォリオの拡大と全体的なセキュリティ・プログラムの改善に取り組み、Workspace ONE Unified Endpoint Management (UEM), Workspace ONE Access and Hub Services, および Workspace ONE Intelligence サービスが ISO 27001, ISO 27017, および ISO 27018 の認証を取得したことを発表いたしました。

今回取得した3つの認証は、VMware による情報セキュリティ管理システム (ISMS)、クラウド・セキュリティ・コントロールの実装、および個人を特定できる情報 (PII) のプライバシー・コントロールにおけるセキュリティ対策が階層構造化されていることを証明しています。

各規格の詳細については、以下を参照ください。また、VMware Trust Center (英語) で Workspace ONE クラウドサービスの ISO 証明書の詳細を確認いただくことも可能です。

ISO/IEC 27001 ISMS 認証	組織のコンテクストで情報セキュリティマネジメントシステムを確立し、実施し、維持し、継続的に改善するための要求事項を規定しています。また、組織のニーズに合わせた情報セキュリティリスクの評価と処理のための要求事項も含まれます。
ISO/IEC 27017 情報セキュリティ管理のための 行動規範	ISO/IEC 27002で規定されている関連する統制に関連する追加の実施ガイダンスと、特にクラウドサービスに関連する追加の実施ガイダンスを提供することで、クラウドサービスの提供及び利用に適用される情報セキュリティ統制のガイドラインを提供します。
ISO/IEC 27018 クラウドにおける 個人情報保護のための行動規範	パブリッククラウドコンピューティング環境において、ISO/IEC 29100のプライバシー原則に従って、個人識別情報(PII)を保護するための対策を実施するために、共通して受け入れられている管理目標、統制、ガイドラインを定めています。

最後まで読んでいただきまして、まことにありがとうございました。

The post Workspace ONE が ISO 27001, ISO 27017, ISO 27018 認証を取得 appeared first on VMware Japan Blog.