Home > Blogs > Japan Cloud Infrastructure Blog

vROps 8.0 はオンプレミスからクラウドまで

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をより活用できると思います。
次回はスーパーメトリックの作成方法をご紹介します。スーパーメトリックの作成も簡単になりましたよ。

vROps 8.0 はオンプレミスからクラウドまで

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のvSANダッシュボード/SDDCコンプライアンス

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

◆メトリック構成◆

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

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

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

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

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

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

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

◆スーパーメトリック◆

スーパーメトリックは、1 つ以上のメトリックを含む数式であり、ユーザー自身が設計するメトリックです。メトリックの組み合わせを単一のオブジェクトまたは複数のオブジェクトから追跡する必要がある場合に使用します。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と同様にメトリックは、「いつ」「何が起きた/起きている」は重要な情報ですよね。メトリックの画面から、各オブジェクトの関係性も確認できますから、関係するオブジェクトに問題が起きているのでは?とあたりをつける場合にも活用できます。次は「アプリケーションの管理」です。前提条件の確認が必須です!!

vROps 8.0 はオンプレミスからクラウドまで

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:アプリケーションの管理②
#7:Workbenchのトラブルシューティング
#8:vROps 8.0のvSANダッシュボード/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を含め、後続のパートで事前に確認すべきことや必要な設定等をご紹介します。

vROps 8.0 はオンプレミスからクラウドまで

Part1:vROps バージョン 8.0でできること①

日本ヒューレット・パッカード株式会社の中川明美です。
仮想マシンやアプリケーションが稼働するインフラの変化により、VMware vRealize Operations Manager(以降vROps)も進化し続けています。 バージョン7.0が2018年9月に、7.5が2019年4月に、8.0が2019年10月にリリースされました。
またvROpsのSaaS製品「VMware vRealize Operations Cloud」も提供を開始します。Operations以外のvRealize製品のSaaS製品の提供が予定されていたり、クラウドファーストのお客様に向けたSaaS製品が提供されています。

-Back Number-

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

今回のBlogタイトルでは「8.0」と明記していますが、7.xから追加された機能も含めます。
8.0までにどのようなUpdateがなされたのでしょうか。
VMware vRealize Operations  8.0のリリースノートからさまざまな改善点が見受けられます。改善はおもに次の5つに分類されます。

「バージョン 8.0でできること」では、次の4つにフォーカスし、Part1でクラウド監視、Part2でおもにアプリケーションの管理についてご紹介します。

  • AWSおよびMicrosoft Azureのパブリッククラウド監視
  • トラブルシューティングWorkbench
  • ネイティブサービス検出
  • アプリケーションの監視

vROps 8.0のインストール直後に表示される「クイックスタート」画面です。
「ようこそ、admin。vRealize Operationsの使用を開始して、ハイブリッドクラウドの最適化、管理、および拡張を先見的に行います。」のメッセージが目に留まります。8.0は画面中央の「クラウドアカウントの作成」から始めます。
この画面から、追加機能の「Workbench」「サービスの検出」「アプリケーションの監視」メニューが確認できますね。

◆クラウドアカウント◆

8.0ではvCenter Serverアダプタインスタンスの追加方法が変更されています。vCenter Serverインスタンスを管理するためには、vCenter Serverのクラウドアカウントを追加します。VMware Cloud on AWSもvCenter Serverのクラウドアカウントから追加します。
右側の画面の「アカウント情報」タブの内容は、以前のバージョンから使用されている方はご存知の内容ですよね。vSANアダプタインスタンスは「vSAN」タブで構成します。

AWSおよびMicrosoft Azureのクラウドアカウントを追加するには、管理パックのインストールが必要です。設定方法は次のドキュメントを参照ください。
▼vRealize Operations Manager での Management Pack for AWS クラウド アカウントの構成
https://docs.vmware.com/jp/vRealize-Operations-Manager/8.0/com.vmware.vcom.config.doc/GUID-56A6674D-396E-475F-884E-03AC54DA6092.html
▼Management Pack for Microsoft Azure のクラウド アカウントの追加
https://docs.vmware.com/jp/vRealize-Operations-Manager/8.0/com.vmware.vcom.config.doc/GUID-15E7FB47-225F-44AC-97E8-BAB7BD8A447E.html

◆AWSおよびMicrosoft Azureの監視◆
使用頻度が高いサービスは、組み込みのダッシュボードが用意されています。


「環境」メニューからも2つのクラウドのサービスを監視することができます。
画面ショットはvCenter Serverオブジェクトを選択した画面ですが、vCenter Serverオブジェクトと同様にクラウドのサービスを監視することができます。

「AWSアダプタ」および「Microsoft Azureアダプタ」では、次のサービスが監視対象となります。

「VMware Cloud on AWS」については、ぜひこちらのBlog(英語)を参照ください。
https://blogs.vmware.com/management/2019/10/vrealize-operations-dashboards-to-monitor-vmware-cloud-on-aws.html?src=so_5a314d05e49f5&cid=70134000001SkJn

◆VMware vRealize Operations Cloud◆

クラウドファーストのお客様にも使用いただけるよう、SaaS製品の「VMware vRealize Operations Cloud」がリリースされます。オンプレミスのvROpsと同様の機能が提供されるそうです。vForum 2019 Tokyoで確認した「VMware vRealize Operations Cloud」に大きな違いは見受けられませんでした。多少画面構成は異なりますが、今までの知識を活用できそうです。
現在はベータ版が提供されています。私はSIGN UPが許可されるのを待っているところです。機会がありましたら、引き続きこちらのBlogでご紹介したいと思います。
https://cloud.vmware.com/vrealize-operations-cloud

◆VMware の監視SaaS製品◆

現在、SaaS製品として、マルチクラウド環境を管理する「CloudHealth by VMware」、仮想環境やクラウドで実行されるアプリケーションを監視および分析する「Wavefront」が提供されています。今回はFree TrialのURLをご紹介します。
ぜひ2つのSaaS製品をお試しください!!
WaveFrontはvROpsと連携できますから、こちらも引き続きご紹介できたらと思います。
▼CloudHealth Free Trial
https://go.cloudhealthtech.com/free-trial-signup
▼Wavefront Free Trial
https://www.wavefront.com/sign-up/

◆まとめ◆

vROpsの改善が目覚ましく、SaaSでも提供されるようになり、さらにCloudHealth by VMwareやWavefrontもリリースされ、情報収集だけでも大変になってきました (笑)
vROpsとWaveFrontを連携すると、オンプレとクラウドで稼働するアプリケーションをWaveFrontで監視することもできます。インフラ担当の方とアプリケーション担当の方で2つのツールから得た情報を共有し、効率のよい管理タスクを実行できそうですね。マイクロサービスやら、コンテナベースのアプリケーションやら、技術向上に向けても忙しくなりますね!
また、ハイブリッドクラウド環境ならvROpsでオンプレミスとクラウドの環境を、複数のクラウド環境を管理されるならCloudHealthも製品選択の対象になりますね。
私が担当するコースを受講するお客様もアプリケーション管理チームの方が増えてきました。「SRE(Site Reliability Engineering)」を目指されているとうかがいます。

今後もVMwareの監視製品を検討いただける内容をご紹介できたらと思います。お楽しみに~!

Deep Security 12.0リリース! VMware関連アップデートのご紹介(3)

DSVAシームレスアップデートによるアップデートの簡素化

 

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

 

8月の VMworld 2019 参加などを挟んで少し時間が空いてしまいましたが、Deep Security™ 12.0(以下、Deep Security)リリースに伴う Deep Security Virtual Appliance(以下、DSVA)関連のアップデートの 1つである ”DSVA シームレスアップデート” についてご紹介をしたいと思います。
これから DSVA を利用される方にはなかなか分かりづらいアップデートになりますが、運用していく上ではアップデート時の選択肢が増えるという意味で有用な機能になっていますので、運用設計の参考にもしていただければと思います。
また、このシームレスアップデートについては、VMware NSX® Data Center for vSphere の場合に利用が可能で、2019年10月(Deep Security 12.0 Update 2)時点では VMware NSX-T® Data Center 環境ではご利用頂けませんのでご注意ください。

 

■ 従来の DSVA のアップデートの方法と DSVA のデプロイの使用

従来、Deep Security のバージョンアップを行う際には Deep Security Manager(以下DSM)をアップグレードした後に DSVA を vCenter Server の“ネットワークとセキュリティ”から DSVA の再配信を行う、というのが一般的な方法でした。
「DSVA の再配信」は、すでに各 VMware ESXi™(以下、ESXi)ホストに配信されている DSVA を一旦「削除」して、改めて新しい OVF ファイルで配信を行う一連の作業の総称で、すべて vSphere Client から vCenter Server を起点に実施する仕様となっています。(同時に配信する Guest Introspection と同様の配信手順になるため、私がトレーニングなどでお話しするときは「DSVA と Guest Introspection は兄弟ですよ!」とお伝えしています。)

ここでアップデートの方法を理解する上で DSVA の OVF ファイルと配信される仮想アプライアンスとしての DSVA の関係性について触れておきたいと思います。
ヘルプセンターなどのオンラインマニュアルには記載がありますが、なかなかご説明をする機会も少ないですね。

 

DSVA を配信するために必要な OVF ファイルは、DSM に格納されていますので、vCenter Server および連携する NSX Manager は DSVA を配信する際に、DSM から DSVA のパッケージをダウンロードした上で各 ESXi ホストへ配信します。(あらかじめ必要なパッケージの DSM へのアップロードとバージョン指定をしておけば、配信時の DSM からの操作は不要です。)

DSVA 配信にあたり、予め DSM へアップロードしておくべきパッケージには以下のものがあります。

  • DVSA パッケージ
  • Linux 版 Deep Security Agent(以下DSA) 64bit 用

DSVA のパッケージは基本的にはメジャーリリース毎(DS11.0、DS12.0など)の初期ビルドのみでリリースされ、その後リリースされるアップデート毎にはリリースされません。各アップデートで提供される DSVA の機能拡張や修正は Linux 版 DSA 64bit パッケージに含まれており、DSVA の配信を実行すると、DSVA をデプロイする際に合わせて指定した DSA のバージョンパッケージによりアップデートが行われます。

 

上記のような仕様であることと、DSVA 配信時には vSphere Client からは配信するバージョンを指定することはできないことから予め DSM で配信したいビルド番号を指定しておくことも必要です。アップデートしたいビルドバージョンは DSM ローカルにアップロードされている DSA パッケージのみが選択可能となっており、デフォルトではローカルで最も新しいビルドを利用するようになっています。

 

デプロイ後の DSVA の状態を見てみると、以下のようにバージョンの情報が2つ表示されます。

  • Virtual Appliance のバージョン          :仮想アプライアンスとして配信されている DSVA のビルド番号
  • Appliance(SVM) のバージョン            :ベースとなった DSVA パッケージ(OVF)のビルド番号

また、同一メジャーバージョンの間でビルドのアップデートを行いたい場合には、DSVA を配信した状態で “Virtual Appliance のバージョン”(=DSA パッケージビルド)によるアップデートを行うことも可能です。
DSVA 毎にアップデートすることが可能ですが、短時間ではありますがセキュリティ保護ができなくなることがありますので留意してください。

 

■ 従来のアップデートの違いとシームレスアップデートの違い

DSVA のアップデートの仕組みをご理解いただいたところで、今回のテーマであるシームレスアップデートについて解説をしていきたいと思います。
従来のアップデートとの違いも含めて整理すると以下のような位置づけになります。

簡単に言ってしまうと、シームレスアップデートは DSVA を配信した状態で OVF の置き換えもしてしまうアップデート方法です。シームレスアップデートを行うと “Virtual Appliance のバージョン”、“Appliance(SVM) のバージョン” 双方がアップデートされます。

ここからはアップデート方法とアップデート中の DSVA の状態を解説していきたいと思います。

 

【シームレスアップデートの実行】
DSM でアップデートしたい ESXi ホストを指定して “Appliance(SVM) のアップグレードを実行

ポップアップ画面の解説にも記載がありますが、シームレスアップデートを実行すると DSVA の削除から指定されたビルドでの再配信までをワンクリックで自動的に実行してくれます。
そのため、アップデート中は該当 ESX iホスト上の仮想マシンに対するセキュリティ保護はできなくなりますので注意してください。
また、DSVA を指定するのではなく、ESXi ホストを指定して実行することもポイントです。
手順はこの 1つだけです。非常に簡単に実行できます。

 

【シームレスアップデートの流れ】
実際のアップデート時の挙動について簡単に見ておきましょう。
DSM 上ではシームレスアップデート実行後しばらくすると ESXi ホストのステータスが“非管理対象”となり、あわせてアップグレード中であることが表示されます。

vSphere Client からも DSVA がパワーオフされて削除されて新たにデプロイされていく推移を確認できます。

 

ここまでシームレスアップデートについて解説してきました。
シームレスアップデートを利用するのか、DSVA を再配信するのかはどのような方針でアップデートするのかによって使い分けて頂くことになると思いますが、vSphere Client 経由で DSVA を再配信する場合にはクラスタ単位での実行となる為、影響範囲が大きいと判断される場合には、シームレスアップデートをご利用頂けるケースもあるのではないでしょうか。
シームレスアップデートを利用のポイントを改めてまとめておきたいと思います。以下の点も踏まえてバージョンアップ計画を立てて頂ければと思います。

  • エージェントアップデートは DSVA を指定するが、シームレスアップデートは DSVA が配信されているホストを指定して実行する
  • DSVA の配信管理は原則 vCenter から NSX Manager 経由で実行されているためクラスタ単位での実行になるが、シームレスアップデートはホスト単位での実行となる
  • 複数の ESXi ホストを同時にアップデートすることはできない(おそらく ESX Agents Manager の制御との兼ね合い)ため、1台ずつ完了確認を行いながら実施する
  • クラスタ単位で DSVA のバージョンが異なることは問題が発生した際に切り分けが困難になることもあるので、アップデートを開始したら速やかに同一クラスタの各 ESXi ホストをアップデートも実行する
  • シームレスアップデートはVMware NSX Data Center for vSphere 環境でのみ実行可能で、VMware NSX-T Data Center 環境ではサポートしていない

ぜひ、アップデート時の1つの選択肢としてご利用を検討してみてください。

 

執筆者:

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

 

【Deep Security 12.0リリース! VMware関連アップデートのご紹介】

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

 

vSAN の新しいカタチ ~ 2 Node vSAN を複数拠点にバラ撒いて集中管理をしましょう ~

みなさま、こんにちは!!アステック株式会社の中平(左)と坂本(右)です。

アステック株式会社は大阪に本社をかまえ、制御系システムソフトウェア開発を中心とした「ソフトウェア開発」部門と、IT インフラのネットワーク設計、セキュリティシステムの設定からハードウェア・ソフトウェアの販売・導入・保守メンテナンス等まで対応している「IT ソリューションビジネス」部門の二本柱を中心とした事業を行っております。

https://www.astec-corp.co.jp/

 

今回は世間で仮想化基盤のデファクトスタンダードとなっている HCI Powered by vSAN の新しい使い方 「複数拠点向け 2 ノード vSAN のバラ撒き構成」をご紹介します。

こちらの記事は日本製薬様というお客様へ実際に導入した実体験を基に、具体的な構成や構築のポイントなどをお伝えします。

※事例化の記事は以下のリンクを参照ください。

https://vmware-juku.jp/casestudy/nihon-pharm/

 

◆案件の概要

  • 各拠点で点在していた NAS および 物理サーバー を 2Node vSAN にリプレース
  • 拠点ごとに個別管理していたインフラを、中央の vCenter Server から集中管理
  • 各拠点の NAS ストレージは、2 Node vSAN 上に構築した Netapp Ontap Select へリプレース
  • バラ撒かれた2 Node vSAN 上の Netapp Ontap Select は 中央の Netapp ストレージとレプリケーションすることで データの DR も実現

 

1.   複数拠点向け 2 Node vSAN  構成とは?

2 Node vSAN といえば小規模の環境でサーバーとストレージを統合するためのソリューションと思われがちかもしれませんが、実は複数拠点を展開している企業での利用も最適です。

 

複数拠点をお持ちのお客様で拠点ごとにストレージや NAS を配置しているパターンは結構ありませんか?

その使い方だと拠点ごとの個別管理で運用負荷が増えていく原因にもなります。

そこで 2 Node vSAN を各拠点にバラ撒いて運用をすると、中央から集中管理が可能になり、運用の効率化と負荷軽減を実現することが可能です。

 

2.    導入構成の Before / After の紹介

2 Node vSAN を各拠点にバラ撒いて、本社やデータセンターに配置した vCenter Server から集中管理するときのネットワーク構成の詳細が書かれた資料は少ないと思いますのでここでは実際の構成をもとに紹介したいと思います。

 

導入前の構成

以前の構成は各拠点に物理サーバー1台とファイルサーバー用の NAS を配置して、本社に配置した NAS ストレージとデータミラーリングを行っていました。

各拠点は単体の物理サーバーで運用していますので冗長化はされていませんでした。

 

導入後の構成

以下が 2 Node vSAN を各拠点に展開したときのネットワーク構成になります。

2 Node vSAN を採用することで、以下のメリットを各拠点に提供できるようになっています。

・拠点のサーバーとストレージ管理をデータセンター側から集中管理できる

・仮想化により vSphere HA による冗長化ができる

・拠点で H/W を新規購入することなくサーバーを構築できる

また、拠点の vSAN ノードの管理インターフェースから Witness 通信をさせるように設定をするという点と、必要に応じてデータセンター側の vSAN Witness アプライアンス と通信ができるようにStatic Route を設定することを忘れないでください。

[ESXi ホストの Witness 通信設定変更コマンド]

例) esxcli vsan network ip add -i vmk1 -T=witness
https://storagehub.vmware.com/t/vmware-vsan/vsan-2-node-guide/vmkernel-interfaces-witness-traffic/

[ESXi ホストの Static Route 設定コマンド]

例) esxcfg-route -a 192.168.100.0/24 192.168.0.1
https://kb.vmware.com/s/article/2001426?lang=ja

 

3.    vSAN バラマキ構成でメリットの出し方

今回の導入でどのようにしてメリットを出したのかをポイントをわけてご紹介します。

3-1.  各拠点の個別管理から集中管理へ移行したいなら vSAN バラマキ構成がベスト

vSAN のばら撒き構成のメリットにはサーバーとストレージの集中管理ができる点にあります。

以下の図は vCenter Serverのログイン画面です。

1つの画面上で全拠点の仮想サーバーの管理はもちろんのこと、ストレージの状況や管理まで行えるため、各拠点に IT 要員を配備しなくても運用ができるようになります。

 

3-2.  拠点で物理サーバーを運用しているなら 2 Node vSAN への移行がベスト

今回のケースではもともと拠点側では NAS と物理サーバーで運用している環境でした。

「2章 導入構成の Before / After の紹介」にあるように、リプレース前の構成では拠点内のサーバーは冗長構成が取られていません。

この環境で仮想環境へ移行するために、サーバーとストレージの新規購入をすると大幅な費用追加を求められます。

こういった環境では 2 Node vSAN にすることで、実際にかかるハードウェアコストを70%まで削減することができました。

以下の画像の赤枠で囲った部分のコストを下げることができます。

もし拠点で物理サーバーを運用している方で、今後仮想環境に変えたいと考えている場合は、3 Tier ストレージ構成ではなく 2 Node vSAN での構成を検討ください。

コスト面 + 運用負荷 + 利便性 などの様々な面でメリットを感じられるはずです。

 

 

3-3.  コストメリットを出すなら vSAN ノードを手組みで構成するのがベスト

vSAN は アプライアンス型、Ready Node 構成 、DIY (手組み構成)がありますが、様々な要望に応えつつ コストメリットを出すなら Ready Node 構成と手組み構成の組み合わせベストです。

具体的な構成方法は VMware が提供している vSAN ハンズオンの中で紹介していますので興味ある方はご参加ください。

※以下のリンクから vSAN ハンズオン資料を取得できます。資料中でもやり方を記載しています。

https://vmware.my.salesforce.com/sfc/p/400000009hQR/a/34000000U33i/VXl.gqTrh8UplMS_8h8le96cN61WQgpj9.Ox10UiW0w

 

今回の案件で採用した構成は最適なコストパフォーマンスを出すために、Ready Node 構成と DIY 構成を組み合わせています。

これは各ハードウェアメーカーが検証することで動作確認が取れている Ready Node 構成を、要件に応じて一部のパーツだけを認定の取れているパーツへ変更するという部分的な手組み構成を組み合わせています。

 

この組み合わせによるメリットはハードウェアの大半が検証済みの構成を採用できるので安定的な稼働を受けられると共に、CPU / Memory / ディスクサイズ(キャッシュ、キャパシティ)などを要件に合わせて柔軟に変えられることで、パフォーマンスとコストメリットの両立を実現できることです。

 

今回の構成では、2 Node vSAN 上に Netapp Ontap Select を実装して、ファイルサーバーとして利用しています。

課題はファイルサーバーを動かすためのディスク容量が必要になるという点はもちろんのこと、快適に利用するためにキャッシュも大容量であることが求められます。

そこで今回の案件では Ready Node 構成に対して以下のような変更をすることで仮想基盤 & ファイルサーバー基盤の両方の要件を満たせる構成を実現しました。

今回のポイントは廉価で高速かつ大容量の SSD をキャッシュに採用して、高速な仮想ストレージを実現するところにあります。

Hybrid 構成の vSAN を採用したため Read Cache が70% 、Write Cache が 30% となります。

今回は1ノードあたり 1.92TB SSD を使用しますので以下の容量になります。

Read Cache のサイズ  ⇨  1.92TB * 0.7 (Read Cache 割合) = 1.34TB

Write Cache のサイズ ⇨  1.92TB – 1.34TB (Read Cache サイズ) = 580GB

これだけの容量があれば仮想基盤とファイルサーバーを共存しても安心ですね!!

※キャッシュ構成の情報は以下の VMware ブログを参照ください。

https://blogs.vmware.com/jp-cim/2016/04/vsan_04.html

 

そして、性能指標でも Read IOPSが57,000 で Write IOPS が27,000 ということで、十分に収容可能であることが確認できます。

https://www.hpe.com/au/en/product-catalog/servers/server-solid-state-drives/pip.specifications.hpe-1dot92tb-sata-6g-read-intensive-sff-2dot5in-sc-3yr-wty-digitally-signed-firmware-ssd.1010129362.html

もし vSAN 導入時のコストでお悩みの際は、手組みの vSAN でコストの最適化を検討してみてください。

 

4.    構築時のポイント

最後に 2 Node vSAN ばら撒き構成を構築する際のポイントをいくつかご紹介します。

 

・2 Node vSAN クラスタ 1つに対して、vSAN Witness アプライアンスが1つ必要です。今回の構成は 3拠点に vSAN ノードをバラ撒いていますので、データセンターに Witness アプライアンスを3台展開しています。

 

・拠点内の vSAN ノード を10G NIC 直結で構成する場合は、Witness アプライアンスに疎通可能なインターフェースに、vSAN Witness 通信のタグをつけるようにしてください。

※詳細な構成は世界で70名ほどしかいない vExpert-vSAN の一人である「Captain 大塚」ことSBC&S 大塚正之さんのブログも参照してみてください。

https://vm-fun.blogspot.com/2019/04/2-node-vsan.html

 

・2 Node vSAN の障害時の挙動を知りたいという方向けに良いブログを見つけました。

vExpert-vSAN の一人である SBC&S 稲葉直之さんのブログで障害時の挙動がサマリにされており、とても見やすいのでそちらを抜粋しつつ紹介します。

https://www.dell.com/support/article/jp/ja/jpdhs1/sln313110/

今回のブログでは 2 Node vSAN の構成や導入に関する情報を書かせていただきました。

お役に立つ情報がまたありましたらこちらでご紹介させていただきますのでご期待ください。

VMware Cloud Foundation でハイブリッドクラウドへ踏み出そう

Part4: VCFでハイブリッドクラウドを実現するには?

ー Back Number ー

#1 「VMware Cloud Foundation (VCF) 」 をご存知ですか

#2    VCFはどんなお客様向けの製品?

#3   自動セットアップの方法とは?

#4   VCFでハイブリッドクラウドを実現するには?

 

日本ヒューレット・パッカード(HPE)で仮想化やハイブリッドクラウドソリューションなどのプリセールスをしている片山倫哉(かたやまともや)です。

 

連載第4回は、ついに本連載のタイトルでもある「ハイブリッドクラウド」についてご説明していきたいと思います。VMware Cloud Foundation(VCF)を使って、ハイブリッドクラウドを実現するための方法です。

これまでのおさらいとして、まずはVCFのコンセプトから再確認してみましょう。

 

連載第1回では、VCFはハイブリッドクラウドを実現するための製品であることやVMware Cloud on AWS も実はVCFをベースとした共通技術(アーキテクチャー)で動いていることをお伝えしました。

共通の技術であれば、それがプライベートクラウド上であってもパブリッククラウド上であってもシームレスに連携できるまではイメージできるでしょう。

 

しかし、よく考えてみてください。

“共通の技術”というだけで簡単にハイブリッドクラウドを実現できるのであれば、みんな苦労しないですよね??

最近、お客様先に訪問した際に「ハイブリッドクラウドはどうやったらいいですかね?」とか、「どうやってオンプレミスとクラウドを使い分けたらいいですか?」などと聞かれることが増えてきました。お客様によって事情や状況が異なりますので一括りに言えませんが、ハイブリッドクラウドを実現するための前段階として、絶対に必要となってくることが1つあります。

 

それは、データセンター運用の標準化 です。

 

デジタルトランスフォーメーションを推し進めていこうとしている中で、データセンターで管理するモノの数や増加し続けるデータの運用に、データセンターの管理者は限界に近づいてきている状況はみなさまご存知のとおりかと思います。

自社のシステムは、その時々で購入した“継ぎ接ぎ”なシステムになってしまっている方も多いのではないでしょうか。しかも、そういうシステムに限って、独自の管理オペレーションが必要だったりするものです。

 

「◯◯さんに聞かないと運用方法がわからない」といった 属人化運用もこういう背景から生まれていきます。

また、日々の運用すら厳しい状況の中、会社の上層部がクラウドを導入することを決めてしまい、クラウド側の管理まですることになると、管理者は精根尽き果てることが容易に想像できてしまう―――。

精根尽き果てるだけだとまだマシで、日々の運用が回らなくなり、業務に支障がでることも出てきます。

 

容易なことではありませんが、長年培ってきたIT資産を管理するノウハウとは別に、運用面も含めデータセンターの標準化について考えるところからハイブリッドクラウドはスタートします。

 

◇ データセンター運用の標準化にはVCF + HPE Synergy ◇

 

ITシステムにおける標準化はアプリやAPIなどから様々なレイヤで必要になりますが、「仮想化インフラの標準化」の課題をマルっと解決できるのがVCFです。

但し、注意してください。単にVCFを導入しただけでは”標準化”されたとは言えません。運用の標準化で一番難しいのは “運用側のマインドチェンジ”と言われています。「今まではこうだったから~」という概念は捨てて運用していくことが重要です。

理解を深めるために、マインドチェンジできていない例とできている例を記載します。

 

マインドチェンジできていない場合

VCFを導入したにもかかわらず、運用フェーズにおいて「サーバー1台だけ個別にESXiのパッチを適用したい」などの要望に応えてしまう。

運用開始直後はVMware社の理想形(VMware Validated Design)になっていたものが、日時の経過と共にかけ離れていき、結局は従来のようなサーバー単位に個別のオペレーション運用になってしまいます。

 

VMware Validated Design

https://www.vmware.com/jp/solutions/software-defined-datacenter/validated-designs.html

 

マインドチェンジできている場合

VCF導入後、運用フェーズにおいても個別管理は許容しない。

特別な運用を許容すると、標準化から離れることになりますので、管理者には“我慢”が必要になってきます。

VCFでは個別管理の代わりに、全体をVMware SDDC Managerで統合管理することで運用の標準化が可能です。

 

具体的な例が「パブリッククラウド」です。パブリッククラウドでは1台1台のサーバーに対して「パッチ適用しますね?」という確認は行わないですよね。事前に予定を告知してくれますが、クラウド事業者側で一括してバージョンアップされます。この運用スタイルをオンプレミス側でも適用していくと考えると理解しやすいのではないでしょうか。

 

◇散らばっている個別システムをVCFへ統合◇

ハイブリッドクラウドの導入の前に、既存のオンプレミス環境を標準化するため、まずVCFを構築します。

次にデータセンターや様々な場所に設置している既存のvSphere基盤や仮想化基盤を新しく構築したVCF環境へ移設していきます。

VCF環境ではVMware SDDC Manager による統合管理が可能ですので、移設していくことにより次々と仮想化基盤の運用が統合されてラクな運用になっていきます。

 

◇ハイブリッドクラウド環境の構築◇

オンプレミス環境の仮想化基盤のVCF環境への統合が完了すると、ついにハイブリッドクラウドを検討する段階になります。

ハイブリッドクラウドを実現することができたときのイメージ図です。

 

具体的にどのような技術を駆使してハイブリッドクラウドを実現するかについて、仮想マシンをハイブリッドで管理するという観点でVMware社からは主に2つの方法が用意されています。

 –Hybrid Linked Mode (HLM) による管理

VMware HCX  を使った相互接続

 

◇Hybrid Linked Mode (HLM) による管理 ◇ 

この方法は、VMware Cloud on AWS 上のvCenter Serverとオンプレミスの vCenter Single Sign-On をリンクさせる手法です。

1つのvSphere ClientのWeb画面からオンプレミス、クラウド、どちらの環境も管理することができ、仮想マシンの移行もシームレスに実現することが可能です。

 

Hybrid Linked Mode の詳細については VMware Docs にも記載されています。

 

Hybrid Linked Mode

https://docs.vmware.com/jp/VMware-Cloud-on-AWS/services/com.vmware.vsphere.vmc-aws-manage-data-center.doc/GUID-91C57891-4D61-4F4C-B580-74F3000B831D.html

 

 

◇VMware HCX を使った相互接続◇

 

聞き慣れない名前かもしれませんが、VMware HCXはオンプレミスのVMware vSphere環境とVMware vSphere ベースのクラウド間をシームレスに接続することができるものです。

驚くべき点は、なんと、既にジェネラルサポート終了を迎えているvSphere 5.5 から最新のvSphere まで対応しているところです。古いvSphere上で稼働中の仮想マシンもハイブリッドクラウドの対象です!適材適所な場所で仮想マシンを稼働させることができます。これぞハイブリッドですよね。

*一部機能制限がありますが、VMware HCX はvSphere 5.1にも対応

 

VMware HCX について

https://cloud.vmware.com/jp/vmware-hcx/faq#general

それぞれのメリットをまとめて比較すると以下の様になりますので、用途に応じて採用をご検討頂ければと思います。

HLM :

  • デプロイに必要なリソースが少ない
  • VSSのみで実装可能
  • Live Migrationの場合、ネットワークに低遅延が必要 (100ms RTT, 250Mbps)

HCX :

  • 標準でL2延伸を実装可能
  • WAN最適化の機能を実装可能
  • Live Migrationの場合でも、ネットワーク遅延の制約が少ない(100Mbps)
  • オンプレミス側のvSphereバージョンの制約が緩い

 

今回は、ハイブリッドクラウドを実現するための心構えや方法について記載しました。

是非みなさまもハイブリッドクラウドを実現するための製品であるVCFと、VCFに最適なプラットフォームである HPE Synergy をご検討ください。

 

片山 倫哉(かたやま ともや)

日本ヒューレット・パッカードのプリセールス部門に所属するプリセールスコンサルタント。

前職ではプログラマー、HPEでは仮想化のサポートエンジニアを経験後、プリセールス部門に転身。

技術が好きでVMware製品やMicrosoft製品の提案や、ProLiantサーバーを中心としたハイブリッドクラウドの提案などに従事。

次世代アーキテクチャのモジュラー型サーバの VCF での活用 ~PowerEdge MX のご紹介~

こんにちは! Dell EMC でパートナー様担当の SE をしている石塚です。ご存知の方々はお久しぶりです!こちらでも宜しくお願いします!!

さて、これまでの 3 回で吉田から Dell EMC のクラウドソリューション Dell Technologies Cloud のコンセプトや概要を高橋から VMware Cloud Foundation On VxRail についてご紹介させて頂きましたが、最終回の 4 回目は私から VMware Cloud Foundation と組み合わせられる面白いアーキテクチャを持った弊社の PowerEdge MX についてご紹介させて頂きます。

 

そもそも PowerEdge MX とは何ぞや?

ご存じではない方も多いと思いますので、まずは PowerEdge MX についてご紹介します。

PowerEdge MX は様々なコンポーネントを柔軟に組み替えたりすることができる「コンポーザブルサーバ」と言うジャンルに属した最新サーバーです。見た目はブレード ? と思われる方も多いかと思いますが、中身は旧来のブレード型サーバとは異なる優れた機能・特徴を持ち合わせております、下記に PowerEdge MX の機能・特徴に関してご紹介させて頂きます。

図 1 : PowerEdge MX 外観

 

〇シャーシのシングルポイント&ボトルネック問題を解消!

vSphere をご利用の皆様であれば、サーバーをクラスタ化して、vSphere HA 等での機能で、サーバー単体の可用性を高めている場合が多いのではないかと思います。しかし、ブレードサーバーによるミッドプレーン問題が発生してしまった場合には、サーバーをクラスタ化しても、ブレードサーバー内の全てのサーバーを停止しなくてはいけないため、システムの完全停止が必要になってしまいます。

ブレード型サーバのミッドプレーン問題とは、 シングルポイントフェイルとして停止を伴うメンテナンスが必要になったり、時間と共に陳腐化してボトルネックになってしまう問題のことです。

PowerEdge MX は、旧来のブレード型サーバではしばしば問題となっていたミッドプレーンに関する問題を解消しています。PowerEdge MX にはいわゆるミッドプレーンと呼ばれるものはありません。 サーバコンポーネントとバックエンドコンポーネント(ネットワークスイッチ等)が下記の図の通り、直接接続するアーキテクチャになっているためです。

図 2 : ミッドプレーン付きの従来モジュールとサーバーとスイッチモジュールを接続する直交コネクタ形状の比較

このおかげで、旧来のブレード型サーバで発生していたようなミッドプレーン故障による仮想サーバーの全停止メンテナンスはありませんし、ミッドプレーンの限界速度によるボトルネックも生じません。

例えば、ミッドプレーン障害(シングルポイントフェイル)を懸念して、管理ドメインとワークロードドメインを複数のシャーシに分散配置するようなことは不要です。1つのシャーシに管理ドメインとワークロードドメインを集約しても安心してご利用頂けます。また、NVMe や今後リリースされる高速デバイスが vSAN にサポートされて活用したとしても、ミッドプレーンがボトルネックになることは回避できます。長期的に変化しながら運用できるシステムになり得ることはご理解頂けると思います。

〇刻々と進化するアーキテクチャを取り込むことが出来る

例えば、vSphere 6.7 では NVMe をサポートされるようになったり、GPU が割り当てられた仮想マシンも vMotion 出来る様になりました。その様な最新デバイスやアクセラレータコンポーネントも、「この時点」で想定していなかったデバイスだったとしても、バックエンドコンポーネントに直接接続することで取り込むことができる様になっています。

また、将来的には、今後リリースされてくる様々な新しい技術 / デバイスをそのスペックを阻害することなく取り入れることができます。

これは PowerEdge MX の設計理念にある、コンピューティングやストレージのリソースを細分割して共有プールを作成し、必要に応じてリソースを拡張性のあるファブリックで接続して割り当てる、と言うキネティックアーキテクチャが実現しています。

このキネティックアーキテクチャを採用している PowerEdge MX は VMware Cloud Foundation や vSAN 等のスケールアウトが容易に行えるプライベートクラウド基盤に最適なハードウェアと言えるのではないでしょうか。

VMware 社も NVMe や GPU 等の最新ハードウェアへの対応を進めておりますが、PowerEdge MX のシャーシは 3 世代に渡るサーバコンポーネントをサポートしておりますので、今後、vSphere のバージョンアップによって最新ハードウェアを vSphere がサポート可能になった場合に、そのままの PowerEdge MX のシャーシで、最新ハードウェアを利用することができます。

よくあるケースとして、導入後に新しい CPU /チップセットが登場したときもシャーシに空きスロットがあれば、そこへ新しいサーバコンポーネントを組み込むことで運用システムへ取り込むことができます。 そして、PowerEdge MX は次世代アーキテクチャとして策定が進んでいる Gen-Z を想定したアーキテクチャでもあります。

図 3 : ユニバーサルプロトコルにより、すべてのコンポーネントが直接通信可能

Gen-Z は Dell EMC や VMware 社等、様々なベンダーが一丸となって取り組む、次世代コンピューティングアーキテクチャです。例えば GPU などのアクセラレータや SCM などのコンポーネントをプール化し、必要に応じてサーバコンポーネントへ割り当てることができるようになります。

PowerEdge MX は Gen-Z を前提としているため、直接接続アーキテクチャになっていると言うわけです。つまり PowerEdge MX は次世代 Ready! なコンポーザブルサーバーなのです。

〇シンプルな管理ツール

PowerEdge MX には冗長化された管理コンポーネント ( OpenManage Enterprise Modular : OME Modular ) が標準搭載されています。この管理コンポーネントを使って、PowerEdge MX シャーシ、サーバコンポーネント、ネットワークコンポーネントなどを一元的に管理することができます。また、PowerEdge MX 以外のサーバやネットワークスイッチなどがある場合にも同様に統合管理ツール (OpenManage Enterprise) から一元的に管理することができます。

また、vCenter Server のプラグインである OpenManage Integrated VMware vCenter(OMIVV)にも PowerEdge MX は対応しているので、「vSphere の管理」と言う視点でも vCenter から一元的にシンプルな管理を実現できます。

図 4 : Open Manger Enterprise を利用した統合管理

PowerEdge MX のセットアップや管理は全て管理コンポーネント(OME Modular)上の GUI(日本語)で行うことができます。CLI フリーです!初めて見る方でも直観的に分かる GUI、シンプルなセットアップウィザードで迷うことなく順番にサーバ設定、ネットワーク設定を行うことができます。これにより運用はかなり容易になると思います。

もちろん、サーバの管理は基準となるサーバを「テンプレート化」することができるので、同一用途のサーバの複数台のセットアップも非常に簡単です。!このアーキテクチャと VMware Cloud Foundation や VMware vSAN などの「スケールアウト」アーキテクチャを組み合わせることで拡張時の TCO を削減することができます。

〇vSAN Ready

スケールアウトがしやすい管理性を持っているため、PowerEdge MX は VMware vSAN との親和性が非常に高いです。その最大のポイントはディスク搭載のアーキテクチャにあります。 まず、起動ディスクにフロントディスクベイを消費する必要がありませんブート専用デバイスである BOSS (Boot Optimize Storage Solution) があるからです。この BOSS のおかげで、全ディスクスロットを VMware vSAN  のために活用できます。

そして、1 サーバコンポーネントあたり 6 つのディスクスロットがあります。VMware vSAN であれば 1 つのキャッシュディスクと 5 つのキャパシティディスクが搭載できます。コンパクトながら必要十分な VMware vSAN 容量を確保することができます。

そして、これでもディスクリソースが足りない、と言うことであればディスク搭載専用コンポーネントで最大 16 個のディスクドライブを搭載することが可能で、各ディスクを自由にサーバコンポーネントへ割り当てることができます。

図 5 : サーバーコンポーネントとストレージコンポーネント

 

VMware Cloud Foundation on PowerEdge MX のメリットは?

上記でご紹介させて頂いた PowerEdge MX と VMware Cloud Foundation を組み合わせるとどんなメリットがあるのか?についてご説明したいと思います。

〇VMware Cloud Foundation Ready なので導入も運用もシンプル & 確実

ご紹介する以上、当たり前ともいえるのですが PowerEdge MX は VMware Cloud Foundation Ready です。確実に構成・導入するためのデプロイメントガイドをどなたでも見れるように公開しています。 また、ディスク構成の面で VMware vSAN との親和性が高いことは上記でご説明していた通りですが、ネットワークの観点でも VMware vSAN との親和性が高いのが PowerEdge MX の特徴です。

サーバコンポーネントの追加はもとより、旧来のブレードサーバでは面倒だったシャーシの追加も「既存のネットワークファブリックに物理的に接続するだけ」で既存ネットワークへの参加が完了するからです。サーバコンポ―ネント設定もテンプレートで即時完了できるので、VMware Cloud Foundaiton でクラスタの拡張や増設をするまでの手間が非常に少なく済みます。

図 6 : MX Fabric Switch を使ったシンプルな増設作業

 

〇変化するシステム要件に柔軟に対応できる

前述のとおり、直接接続アーキテクチャのおかげで PowerEdge MX はコンポーネントを自由に組み替えることができます。「現時点」でのシステム要件を踏まえて設計・導入したとしても、そのシステムがいつまで有用なのかは、アーキテクチャやビジネスの変革スピードが激しい昨今では予想することは難しいと思います。

しかし、PowerEdge MX であればその変化に対応することができることは上記の通りですし、VMware Cloud Foundation と組み合わせることでシステムライフサイクル管理=既存システムの「縮小」や「削除」や、新しいコンポーネントを搭載したサーバコンポーネント群で新しいワークロード向けクラスタをデプロイすることが容易です。PowerEdge MX+ VMware Cloud Foundation は変革するシステム要件に対応するためのベストな組み合わせではないでしょうか!?  

図 7 : PowerEdge MX と Cloud Foundation を用いた柔軟性のある仮想環境

 

〇特殊ワークロード/システム要件に対応できる

特殊なワークロード/システム要件、例えば「アプリケーションと連携したデータ保護がしたい」 等の場合には、外部ディスクの利用が最適なシステムも存在するかと思います。

この様な要件がある場合にはやはりエンタープライズのストレージが最適ですが、Dell EMC には歴史と実績を誇るエンタープライズストレージ Symmetrix の血統を受け継ぐ PowerMax があります。この PowerMax も VMware Cloud Foundation との接続をサポートしています。

なお、VxRail も FC HBA を追加可能なので、PowerMax を接続することももちろん可能です。

さらに PowerEdge MX + PowerMax なら様々なコンポ―ネントと組み合わせることで特殊ワークロードへの対応もできますし、長期的なサポートアーキテクチャでもあるので相乗効果を生むことができます。そして、今後出てくるであろう NVMe Over Fabric であったとしても PowerEdge MX なら直接接続アーキテクチャでそのメリットを活かしきることができます。

今回の VMware Cloud Foundation のご紹介とは少し離れてしまいますが、PowerEdge MX 内のサーバコンポ―ネントをVMware Cloud Foundation 管理下におくものと、それ以外で混ぜて利用することも可能です。

例えば基本的には VMware Cloud Foundation で利用する基盤として運用しているが、データベース等の特定アプリケーションにおいて数台の物理サーバを準備しなければならない、と言う場合も多いのではないでしょうか。その様な時、PowerEdge MX であれば個別運用サーバを準備することなく、サーバリソースとしては 1 つのシステムとして運用をまとめることができます。

図 8 : PowerEdge MX とPowerMax の接続

 

まとめ

コンポーザブルサーバの PowerEdge MX と VMware Cloud Foundation を組みあわせることによるメリットはご理解頂けたでしょうか。PowerEdge MX に関しては、私どものブログでも全10話(予定)と言う熱い思いが溢れている記事もあるので、是非ご覧下さい。

図 9 : プライベートクラウド・ベストスターターキット

 

今回の連載を通して、Dell Technologies クラウドによるハイブリッドクラウドのビジョンから、VMware Cloud on VxRail ・VMware Cloud on PowerEdge MX 等の各製品・ソリューションをご紹介させて頂きました。今回の連載を読んで頂き、もし、具体的なお話をお伺いしたいというご要望がございましたら、是非、お気軽に弊社営業までお問い合わせ頂ければ幸いです。

<連載リンク>

第1回 ハイブリッドクラウドをより身近な存在に!~Dell Technologies Cloud~

第2回 VMware Cloud Foundation on VxRail から始めるオンプレクラウド

第3回 VMware Cloud Foundation on VxRail の構築と運用

第4回 次世代アーキテクチャのモジュラー型サーバの VCF での活用 ~PowerEdge MX のご紹介~

Deep Security 12.0リリース! VMware関連アップデートのご紹介(2)

Deep Security 12.0  VMware NSX-T環境におけるエージェントレス型セキュリティの実装概要

 

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

前回のブログで Trend Micro Deep Security™ 12.0(以降 Deep Security)のリリース概要と VMware 関連のアップデートについてご紹介しました。
今回は、その中でも特に大きなアップデートである VMware NSX-T® Data Center(以降 NSX-T Data Center)への対応について、技術的なポイントを踏まえてご紹介をしていきたいと思います。

 

改めて、“NSX-T Data Center への対応”の概要についておさらいしておきましょう。
<NSX-T Data Center 環境で Deep Security 12.0 が連携して提供できる機能>

  • NSX Manager & vCenter Server 連携による仮想マシン情報の取得
  • VMware ESXi™(以降 ESXi)に対して NSX-T Data Center を展開することで Deep Security Virtual Appliance(以降DSVA)によるエージェントレス型不正プログラム対策を提供 (対象となる仮想マシンは Windows OS のみ)
  • 不正プログラム対策イベント検出時の NSX Manager へのセキュリティタグの付与による分散ファイアウォールによる自動隔離の実装

なお、上記の連携ができるのは、Deep Security 12.0 (Deep Security 12.0 Update1 以降の利用を推奨)と NSX-T Data Center 2.4.1 以降の組み合わせです。また、ハイパーバイザは ESXi のみで、KVM には対応していません。

 

■ NSX-T Data Center 環境における Deep Security の配置

まず、NSX-T Data Center 環境において Deep Security がどのように配置されるのかを確認しておきましょう。

Deep Security においてエージェントレス側セキュリティを提供するためには DSVA を保護対象としたい各 ESXi へ配信をすることが必要になります。また、DSVA の配信は VMware NSX の仕様として個別 ESXi ホストごとへの配信はできず、クラスタ単位で行います。

ここで、VMware NSX Data Center for vSphere (以降はNSX Data Center for vSphere)をご存知な方は Guest Introspection も配信しないの? と思われるかもしれません。NSX-T Data Center では、仮想アプライアンスとしての Guest Introspection の配信をする代わりに ESXi ホストに導入される Ops Agent が 3rd Party 連携に必要な機能を提供する形になっています。

 

また、NSX-T Data Center 2.4 より NSX Manager に Controller が内蔵されたことにより、商用利用では NSX Manager を3台構築することが必要になりました(NSX Controller の仕様に依存)。この点も本番環境への導入時にはリソース面の確保など留意しておきたいポイントですね。

ちなみに、Deep Security Manager(以降 DSM)から NSX-T Data Center の NSX Manager の登録を行う際は NSX-T Data Center の NSX Manager で設定できる Cluster VIP を設定することが推奨されています。

 

 

そしてもう1つ。DSVA を配信する際には予めいくつか準備をしておく必要がある設定があります。

それがトランスポートゾーンの設定です。トランスポートゾーンを理解する上で必要な用語を以下に簡単にご紹介しておきます。

トランスポートゾーン
エージェントレス型セキュリティを提供(=DSVA を配信)したいクラスタに展開される仮想ネットワーク
トランスポートノード
NSX-T Data Center においてトラフィック転送を司るノード。トランスポートゾーンを展開したい ESXi ホスト(クラスタ)を指定
トランスポートノードプロファイル
トランスポートノードとして指定された ESXi ホスト(クラスタ)に対してトランスポートゾーンやそれに紐づくアップリンクポート、物理ポートなどを規定するためのプロファイル
N-VDS:NSX Virtual Distributed Switch
トランスポートノードでスイッチング機能を実行する NSX ソフトウェアコンポーネント、トランスポートノードプロファイルの中でアップリンクポートや ESXi ホストの物理 NIC などを設定

 

Deep Security を展開する観点から整理すると、DSVA で保護したい対象が所属する仮想ネットワークを “トランスポートゾーン” として指定し、その仮想ネットワークを展開したい ESXi ホスト(クラスタ)を “トランスポートノード” として指定します。

ESXi ホスト上で展開される仮想スイッチの設定は “トランスポートゾーンプロファイル” により行い、DSVA の展開は必ずトランスポートゾーンに所属している ESXi ホスト(クラスタ)を指定する必要があります。 “トランスポートゾーン” の設定がされていないとエージェントレス型セキュリティ(NSX-T Data Center では “エンドポイントの保護” と呼ぶ)を提供することができません。

また、上記設定を行うことによって、ESXi ホスト上に自動的に分散仮想スイッチ(vDS)が展開されます。NSX Manager から展開された分散仮想スイッチは vCenter Server から設定を変えることはできず、また、既存の分散仮想スイッチに対して NSX-T Data Center で提供するサービスを提供することもできませんので、設計、構築時には留意しておいてください。

 

 

■ NSX-T Data Center 環境における管理面でのポイント

実際の管理面でのポイントについても少し触れておきましょう。

  • NSX-T Data Center のサービスは NSX-T Data Center の NSX Manager から直接管理を行うため、vCenter Server を中心とした管理体系から NSX-T Data Center の NSX Manager GUI による管理へ変更
    → NSX-T Data Center の NSX Manager から vCenter Server をコンピュータノードとして登録します。
  • Deep Security での不正プログラム対策イベント検出時のセキュリティタグ付与による分散ファイアウォールでの自動隔離は NSX Data Center for vSphere 同様に可能
  • 各仮想マシンの NSX サービスステータスは NSX-T Data Center の NSX Manager で管理
    → vCenter Server では仮想マシンに対する NSX セキュリティグループやセキュリティタグは表示されなくなっています。また、それに伴って DSM 上でも NSX セキュリティグループやセキュリティタグのステータスは表示されなくなっています。

これは NSX-T Data Center が NSX Manage を中心に運用を行っていくことを前提に設計されて、vCenter Server だけでなく KVM や今後展開される他のハイパーバイザ、クラウドへの対応を見据えた変更なのだと思います。

 

また、Deep Security の連携において大きな影響がある部分としては、以下の点が挙げられます。

  • NSX-T Data Center セキュリティプロファイル (ポリシー) に対する Deep Security ポリシーの連携が未対応

従来、NSX Data Center for vSphere と Deep Security の連携では、NSX が提供するセキュリティポリシーのゲストイントロスペクションサービスで Deep Security が保持するポリシーを指定することで仮想マシンの生成時にゲストイントロスペクションサービスと同時に Deep Security のポリシーの有効化までを自動的に行うことができました。現時点(2019年8月時点)では、NSX-T Data Center の“サービスプロファイル“で Deep Security ポリシーを適用することはできません。

仮想デスクトップ環境でフローティング割り当てによる仮想マシンの生成を行っている場合には、サービスプロファイル側では ”Default (EBT) ” を設定し、Deep Security 側では vCenter Server 上で仮想マシンの生成を検出した際に DSM が該当の仮想マシンに対して自動的にポリシーを割り当てる ”イベントベースタスク”を合わせて設定しておくことでポリシー適用の自動化を図ることができます。

イベントベースタスクの詳細については Deep Security ヘルプセンターをご参照ください。

 

以上、Deep Security 12.0 と NSX-T Data Center 2.4.1 の連携についてご紹介しました。
最後に、実際の導入にあたっては、Deep Security 12.0 Update 1(8/9にリリース済み)からがVMware も含めてサポートする予定のビルドとなりますので、こちらをご利用いただくようにしてください。

(トレンドマイクロの互換性マトリックスでは Deep Security 12.0 から利用できるように記載されていますが、VMware の互換性に関するサポート承認もされる予定のバージョンは Deep Security 12.0 Update 1 からになる予定です。)

 

執筆者:

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

 

【Deep Security 12.0リリース! VMware関連アップデートのご紹介】

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

 

VMware Cloud Foundation on VxRail の構築と運用

Dell EMC で VxRail の製品技術担当をしている高橋岳です。

4 回シリーズで Dell EMC のクラウドソリューションと具体的な製品をご紹介していますが、今回は 3 回目となります。

前回は VMware Cloud Foundation on VxRail (以下、VCF on VxRail) の概要と特徴についてお話をいたしましたので今回は構築、運用にフォーカスをあててご説明をして行きたいと思います。

VMware Cloud Foundation on VxRail の構成条件

1. 前提条件

下記の条件がありますので、事前の確認をお願い致します。

  • 現行リリースでは、VCF on VxRail は新規構築のみで利用可能です。
  • 既存の VxRail クラスタを Workload Domain (アプリケーション稼働用クラスタ) として構成して、Management Domain (運用管理用クラスタ) のみを追加構築する様な構成は出来ません。
  • Workload Domain に既存/新設の vSAN Ready Node クラスタと VxRail クラスタを混在させることは出来ません。
  • VxRail 2 ノードクラスタ構成を VCF on VxRail として利用することは、現時点では出来ません。

2. ハードウェア

  • VCF on VxRail 構成であっても、VxRail 14G ベースの全てのモデル(E, P, V, S, Gシリーズ)が利用可能です。
  • 最小構成は Management Domain = 4ノード、Workload Domain = 4 ノードの組み合わせで計 8 ノード構成からとなります。

 

3. ネットワーク

通常の VCF と同様 Bring Your Own Network (BYON : ご自身での事前構築済みネットワーク) として、VCF で必要なネットワーク要件を満たすことが可能であれば、既存新設を問わず利用可能です。

但しスイッチの VxRail との接続要件として下記が要件となります。

  • IPv4,v6 ともサポートしていること
  • VxRail が接続されるポートで IPv6 マルチキャストが利用出来ること

→ VxRailクラスタではノード検出等の為に IPv6 マルチキャストを利用しています

  • 10GbE もしくは 25GbE の接続が可能であること
  • iDRAC を利用する場合は 1GbE の接続が可能であること

また VCF on VxRail として、下記も要件となります。

  • マルチキャスト (上述の VxRail クラスタの条件として)
  • ジャンボフレーム
  • Workload Domain スヌーピング & スヌーピングクエリア(推奨)
  • BGP (NSX Edge Gateway とピアー接続が必要な場合)
  • Hardware VTEP (マルチラックデプロイメントが必要な場合)

ネットワークスイッチについては上記をサポートしているものであれば、利用可能です。

弊社の Smart Fabric 対応スイッチも、もちろん利用可能です。

Smart Fabric の詳細については、次回の筆者である弊社石塚がまとめた Blog もぜひご参照下さい。

VxRail+Smart Fabric Service構成での導入 ~準備編~

 

4. ソフトウェア

VCF バージョン 3.7 から VCF on VxRail の対応は始まり、2019/8/5 現在での最新バージョンは 3.8 となります。

[VMware KB] Supported versions of VMware Cloud Foundation on VxRail (67854)

 

VCF on VxRail では構成出来る VxRail のバージョンと VCF のバージョンが対になっています。

例えば、2019 年 08 月時点での  VCF on VxRail の場合、

 

  • VxRailソフトウェア = 4.7.212
  • VCF = 3.8

の組み合わせで利用する形となります。

 

詳細はバージョン毎のリリースノート及び Build Of Materials (BOM) をご参照下さい。

VMware Cloud Foundation 3.8 on Dell EMC VxRail Release Notes

 

 

 

 

 

 

 

 

表 1 : VCF on VxRail 3.8 BOM

なお、VCF on VxRail 3.8 から Workload Domain での NSX-T の構成が可能になりました。

VCF on VxRailの構築

では、VCF on VxRail の構築手順を確認して行きましょう。まず VxRail で vCenter を構築する際には 2 種類の方法があります。

  • 内部 vCenter (Embedded vCenter) :

VxRail クラスタの vSAN データストア内に vCenter を構築する構成の事です。VxRail の標準的な vCenter 構築パターンです。

  • 外部 vCenter (External vCenter) :

通常の vSphere として vCenter を構築するのと同様、VxRail クラスタの外に vCenter を構築する構成の事です。既存の vCenter を運用しており、その管理配下に VxRail をデプロイする場合はこちらの構成になります。

 

 

 

 

 

 

 

 

図 1 : VxRail の vCenter 構造

 

上記の通り VxRail の構成には、”内部 vCenter” と “外部 vCenter” の 2 つの構成があることを前提に話を進めていきます。

おさらいとなりますが、VCF on VxRail ではオプションコンポーネントを含めて、下記の製品群が利用可能です。

 

図 2 : VCF on VxRail のコンポーネント

コアコンポーネントの初期デプロイとしての大きな構築の流れは、下記の通りです。

【VCF on VxRail の管理層の初期デプロイ】

  1. 事前要件を確認
  2. VCF の Management Domain として、内部 vCenter 構成で VxRail クラスタを構築
  3. VCF 要件に合わせて外部 vCenter 構成に変更
  4. VCF Cloud Builder 仮想マシンをデプロイ
  5. Cloud Builder を使って、VCF を構築(Bring Up)
  6. vCenter のライセンスを SDDC Manager に適用

 

【VCF on VxRail のサービス環境のデプロイ:運用】

  1. 外部 vCenter 構成として VxRail クラスタを Workload Domain としてデプロイ
  2. (必要に応じて) Workload Domain の削除

 

では、各手順を追ってご説明していきます。

【VCF on VxRail の管理層の初期デプロイ】

  1. 事前要件を確認:

VCF on VxRail を構築する上で必要なパラメータを全て確認し、お客様と決定して頂くフェーズです。Dell EMC で行う場合は、プロデプロイという構築サービスの中で対応する項目となります。下記項目を確認して行きます。

  • Management Domain, Workload Domain の構成決定
  • VCF の Bring Up 用構成シート (VCF Configuration Spreadsheet) の完成
  • VxRail ノードが VCF on VxRail で指定されたバージョンで初期イメージが展開されている事
  • 全てのネットワークスイッチがラッキングされ、ケーブリングが完了している事
  • DNS が適切にセットアップされている事
  • VXLAN のサブネットで DHCP サーバが適切にセットアップされている事

 

  1. VCF の Management Domain として、内部 vCenter 構成で VxRail クラスタを構築する:

Management Domain 用の VxRail クラスタをデプロイします。標準的な内部 vCenter 構成として構築します。VxRail の初期デプロイは VxRail Manager を初期構築ウィザード形式で利用しますが、この画面は日本語化も可能です。

本ブログでは詳細は割愛致しますが、弊社のパートナー様であれば、下記からデモをご確認頂けますので、ログイン後、”VxRail” とキーワード検索をしてみて下さい。

 

Dell EMC Demo Center

 

 

 

 

 

 

 

 

 

図 3 : VxRail クラスタの標準構築

 

  1. VCF 要件に合わせて外部 vCenter 構成に変更

構築した内部 vCenter を、外部 vCenter としてコンバートします。VxRail Manager 仮想マシンの中にコンバート用の Python スクリプトが用意されておりますので、そちらを実行します。

 

 

 

 

 

 

 

 

図 4 : 外部 vCenter 構成への変更
  1. VCF Cloud Builder 仮想マシンをデプロイ

Management Domain の外部 vCenter と連携して NSX や SDDC Manager 等を自動構築するために、VxRail 用の Cloud Builder を OVF からデプロイします。

図 5 : Cloud Builder for VxRail のデプロイ

 

  1. Cloud Builderを使って、VCF を構築(Bring Up)

vSpherevSAN 及び各種ハードウェアファームウェアのライフサイクル管理を行う VxRail Manager と連携する専用の Cloud Builder を使って残りの構成を進めて行きます。Cloud Builder は 2019 年 08 月時点では日本語化されていません。

  • Cloud Builder 起動後、完成させた Configuration Spreadsheet(Excel ファイル)をアップロードし設定の整合性を確認します

図 6 : Cloud Builder へ設定ファイルの読み込み
  • 設定内容の検証完了後、SDDC の設定(Bring Up)を行っていきます

PSC → SDDC Manager → NSX をデプロイし、VxRail Manager との連携後 Bring Up 完了となります。以降は SDDC Manager が利用可能になります。

 

 

 

 

 

 

 

 

 

図 7 : SDDC Bring Up プロセス

 

 

 

 

 

 

 

 

 

図 8 : SDDC Manager Dashboard

 

  1. 各種ライセンスキーを SDDC Manager から適用

Workload Domain 用の vCenter サーバ、vSAN、NSX-V、NSX-T (Workload Domain 用のみ) のライセンスを適用します。

 

ここまででデプロイされた Management Domain とこれから作成する Workload Domain の関係をオプション構成も含めた形で図にまとめます。

 

 

 

 

 

 

 

 

図 9 : VCF on VxRail Virtual infrastructure Workload Domain に NSX-V を使った構成サンプル

図 9 上部の  ”Management Workload Domain” の箱の中にあるコンポーネントの内、下のWorkload Domain1,2 と接続されている vCenter Server、NSX-V Manager 以外のものが構成完了した状態となります。

ここからは VCF としての運用フェーズとなり、お客様の環境に合わせてサービス用の VI(Virtual Infrastructure : 仮想基盤)Workload Domain を作成して行きます。

 

【VCF on VxRailのサービス環境のデプロイ:運用】

 

  1. 外部 vCenter 構成で VxRail クラスタを Workload Domain としてデプロイ

    • SDDC Manager 上部の “+ Workload Domain” をクリックし、“VI – VxRail Virtual Infrastructure Setup” を選択します。

 

 

 

 

 

 

 

図 10 :  Workload Domain の作成 #1
  • Workload Domain のパラメータを入力します。

 

 

 

 

 

 

図 11 :  Workload Domain の作成 #2 – パラメータ入力 –
  • 入力されたパラメータに従って、SDDC Manager は VxRail Manager と連携して VxRail クラスタと外部 vCenter、NSX のデプロイを実施します。最初に SDDC Manager が外部 vCenter をデプロイし、その後 VxRail クラスタを構築します。

 

 

 

 

 

 

 

図 12 : Workload Domain の作成 #3 –WLD用外部 vCenter デプロイ-
  • VxRail クラスタの構築後、SDDC Manager に作成した VxRail クラスタを認識させ NSX を展開します。

 

 

 

 

 

 

 

 

図 13 :  Workload ドメインの作成 #4 –SDDC Manager によるデプロイ-

 

  • NSX の展開が完了すると、SDDC Manager からは運用可能な Workload Domain として認識されます。

 

 

 

 

 

 

 

 

図 14 : Workload ドメインの作成 #5 – デプロイ完了-

 

  1. (必要に応じて) Workload Domain の削除

何らかの理由で Workload Domain を削除する場合も、SDDC Manager からオペレーション可能です。

  • SDDC Manager の左ペインから Workload Domains -> 右フィールド内の Virtual Infrastructure 下部の  “View DETAILS” を選択します
  • 削除したい Workload Domain を選択します
  • 確認のウィンドウが出て来ます。対象の Workload Domain 名を入力の上、“DELETE WORKLOAD DOMAIN” ボタンを押します

 

 

 

 

 

 

 

図 15 : Workload Domain の削除 #1

 

  • Workload Domain 削除のオペレーションが完了後、対象の Workload Domain が表示から消え削除が完了します

 

 

 

 

 

 

 

 

図 16 : Workload Domain の削除 #2 –削除のプロセス-

Workload Domain 全体の削除について説明致しましたが、Workload Domain 内でのノード及び VxRail クラスタの拡張、削除も SDDC Manager から作業可能です。

 

まとめ

 

VCF を VxRail と合わせて利用することで、SDDC 環境を利用する上での利便性、管理性が格段に向上することをご説明してきました。

ポイントとしては、下記になります。

 

  • VCF を使って自動で標準的な SDDC 環境をシンプルに短期間でデプロイ
    • VxRail の標準構築プロセスで短時間でのオペレーションが可能

 

  • VxRail 上に構築する事で、ファームウェアを含めたフルスタック なライフサイクルマネジメントが可能に
    • VCF on VxRail であれば SDDC 環境全体のライフサイクル管理が可能

 

  •  SDDC Manager が VxRail Manager と連携することで VCF on VxRail が動作
    • Dell EMC と VMware との共同開発で、管理ツールも密結合しシームレスな連携を実現

 

VxRail を使う事によるメリットを是非感じて頂きたく思います。

ご興味がございましたら弊社 Dell EMC もしくはパートナー様にお問い合わせ頂けますようお願い致します。

長文にお付き合い頂き、誠に有り難うございました。

<連載リンク>

第1回 ハイブリッドクラウドをより身近な存在に!~Dell Technologies Cloud~

第2回 VMware Cloud Foundation on VxRail から始めるオンプレクラウド

第3回 VMware Cloud Foundation on VxRail の構築と運用

第4回 次世代アーキテクチャのモジュラー型サーバの VCF での活用 ~PowerEdge MX のご紹介~