Home > Blogs > Japan Cloud Infrastructure Blog > 月別アーカイブ: 2019年8月

月別アーカイブ: 2019年8月

次世代アーキテクチャのモジュラー型サーバの 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.  
     

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 のご紹介~

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

Deep Security 12.0 リリース内容とVMwareソリューション関連のアップデート

 

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

 

2019年6月に総合サーバセキュリティ製品である Trend Micro Deep Security™ の最新バージョン12.0 がリリースされました。
今回から3回に分けて Deep Security 12.0 のリリースの内容と VMware 製品との連携に関わるアップデートについてご紹介をしていきたいと思います。

 

ハイブリッドクラウドセキュリティを実現する Trend Micro Deep Security™

まず、改めて Deep Security の特徴を簡単にご紹介します。
Deep Security は、物理、仮想化、クラウドなどの環境にかかわらずサーバセキュリティに必要な機能を提供することができるセキュリティソリューションです。

 

セキュリティの統合管理を行う Deep Security Manager(DSM:Deep Security における管理マネージャ)は、VMware vCenter Server (以降、vCenter Server) や AWS マネジメントコンソールなどのインフラ基盤と連携することが可能です。これは IT 管理者にとっては非常に有用な機能で、仮想マシン(またはインスタンス)が生成されたことをリアルタイムに検出し、必要に応じて予め設定をしておいたセキュリティ保護を自動的に適用することを可能とします。「セキュリティ適用の可視化、統制」と「運用の簡素化」を両立でき、VMware 環境では vCenter Server さえあれば、連携が可能となりますので、ぜひ試していただきたいと思います。

 

そして VMware vSphere 環境では、VMware NSX Data Center と組み合わせて利用することで「サーバ単位」で適切なアクセス制御とサーバ要塞化を実現することが可能となります。

 

Deep Security 12.0 新機能とアップデート

次に Deep Security 12.0 で追加された新機能・アップデート内容を紹介します。
Deep Security 12.0は、Deep Security 11.1~11.3(Feature Release)でアップデートされた内容と Deep Security 12.0 で新たに追加された新機能、アップデートで構成されています。
アップデートのポイントは大きく2つに分けられます。

  • コンテナなど新しい環境/技術への対応
  • セキュリティオートメーションの促進

主なアップデートの内容は以下の通りです。

詳細はこちらをご参照ください。

 

Deep Security12.0  VMware 関連アップデート

そしてここから本題である Deep Security 12.0 における VMware 関連のアップデートをご紹介していきます。
VMware ソリューションのアップデートは、以下の2つになります。

  • VMware NSX-T Data Center (以降、NSX-T Data Center) 連携によるエージェントレス型セキュリティの実装
  • DSVA バージョンアップ手順の大幅削減(シームレスアップデート)

それぞれについて、アップデートの概要を以下にご紹介していきます。

 

■ NSX-T Data Center 連携によるエージェントレス型セキュリティの実装

今回のアップデートの目玉と言ってもいいのがこの「NSX-T Data Center 連携」です。従来、VMware NSX Data Center for vSphere (以降は、NSX Data Center for vSpehre) 環境では、セキュリティVM である Deep Security Virtual Appliance(DSVA)を VMware ESXi (以降、ESXi)ホストに配信することで、エージェントレス型のセキュリティ対策を提供してきました。VMware Horizon による仮想デスクトップ環境や Windows サーバに対するエージェントレスでの不正プログラム対策(ウイルス対策)のために多くのお客様で利用を頂いておりますが、Deep Security 12.0 から NSX-T Data Center 環境でも利用して頂けるようになりました。

NSX-T Data Center 環境で Deep Security 12.0 が連携して提供できる機能は以下になります。

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

 

DSVA は NSX Data Center for vSphere と同様に各 ESXi ホストに配信し、配信する際のパッケージ(DSVA の OVF ファイル)は共通化されています。一方で、NSX Data Center for vSphere と NSX-T Data Center では構成要件や実装方法が異なるため、実際の導入にあたっては NSX Data Center for vSphere のイメージのままだと理解しづらい点があるので留意が必要です。Deep Security の観点から NSX Data Center for vSphere と NSX-T Data Center での相違点を整理しておきましょう。

  • セキュリティ仮想アプライアンス(SVM)としての Guest Introspection 廃止
    • NSX-T Data Center の NSX Manager から各 ESXi ホストに展開される Guest Introspection Service によってエージェントレス型ウイルス対策(エンドポイントセキュリティ)を提供
  • Guest Introspection Service が利用可能(=DSVAが展開可能)なハイパーバイザは ESXi のみ(KVMは対象外)
  • 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 をノード登録
  • 各仮想マシンの NSX サービスステータスは NSX-T Data Center の NSX Managerで管理
    • vCenter Server では仮想マシンの NSX セキュリティグループやセキュリティタグは表示できない
  • NSX-T Data Center セキュリティプロファイル(ポリシー)に対する Deep Security ポリシーの連携は未対応
  • NSX-T  Data Center 2.4 より NSX Manager に Controller が内蔵されたことにより、商用利用では NSX Manager を 3台構築することが必要(NSX Controller の仕様に依存)
    • DSM からの登録は NSX-T Data Center の NSX Manager Cluster VIP を設定することを推奨

 

■ DSVA バージョンアップ手順の大幅削減(シームレスアップデート)

Deep Security12.0 から NSX Data Center for vSphere 環境において、DSM の UI から DSVA の OVF をアップグレードできるようになりました。
従来、配信済の DSVA の OVF ファイルも含めたバージョンアップを行う際には、vCenter Server の“ネットワークとセキュリティ”から該当するクラスタに所属するホスト上の DSVA すべてを一度削除し、新しい OVF ファイルから再デプロイする必要がありました。新たに実装されたシームレスアップデートにより、DSM GUI から DSVA が配信されているホストに対してセキュリティアプライアンスのアップグレードを実行することが可能になりました。これによってホストごとに順次アップデートすることが可能となると同時に、セキュリティ機能の停止もアップグレード中の一時的なものに短縮することができます。より簡易にかつサービス影響をより少なく行うための選択肢が増えたことになります。
※従来の vCenter Server からの DSVA の再配信も行うことは可能です。
※シームレスアップデートについては、NSX-T Data Center 環境では実行できません。

次回からは今回ご紹介したアップデートについてもう少し詳しくご紹介をしていきたいと思います。

 

執筆者:

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

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

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

 

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

 

Dell EMC で VxRail の製品技術を担当している高橋です。Japan Cloud Infrastructure Blog で初めて寄稿させて頂きますので、よろしくお願い致します。

4 回シリーズで Dell EMC のクラウドソリューションと具体的な製品をご紹介していますが、2 回目の今回では VMware Cloud Foundation on VxRail  (以下、VCF on VxRail) のご紹介を致します。

 

Dell EMC HCI 製品の中の VxRail

 

Dell EMC では広範なハイパーコンバージドインフラストラクチャ (以下、 HCI) ソリューションを取りそろえておりますが、グループ会社の枠組みである Dell テクノロジーズとして完結しているソリューションをまとめると下記の図になります。

 

図 1:Dell EMC の HCI ポートフォリオ

 

大きく 2 つの流れがあり、弊社開発のソフトウェアデファインドストレージ (以下、SDS) である VxFlex OS を利用したソリューションと VMware vSAN (以下、vSAN) を利用したソリューションがあります。

vSAN ベースの製品としては Power Edge 版の vSAN Ready Node と vSAN HCI アプライアンスの VxRail があり、VxRail は VMware 社との共同開発製品として Dell テクノロジーズの SDDC ソリューションの中核をなす製品です。また現時点では北米でのみ発表済みですが、Top of Rack スイッチを含めた統合型ラックタイプ HCI 製品として、VxRail Integrated Racks も日本市場への投入を予定しています。

 

ハードウェア構成は全て弊社 14 世代の Power Edge サーバをベースにしており、3 種類の筐体で 5 モデルがあります。

注:ここでのノードは、1 ESXi ホストもしくは 1 物理サーバと同義です

 

  1. 1U1 ノード構成:

    1.  ロープロファイルで汎用性の高い E シリーズ(R640 ベース)
  2. 2U1 ノード構成:

    1.  汎用性の高さとストレージ容量確保を両立している P シリーズ(R740 ベース)
    2.  3D-VDI 等に必要な NVIDIA 社の vGPU カードを搭載可能な V シリーズ(R740 ベース)
    3.  5 インチ大容量 HDD を利用しコストパフォーマンス良くストレージ容量集約可能な S シリーズ(R740xd ベース)
  3. 2U4ノード構成:

    1.  1U ハーフラックサーバを 2U 筐体内に 4 台収めた高密度コンピュート集約型の G シリーズ(C6420 ベース)

 

Power Edge とほぼ同様の幅広い選択肢の CPU, メモリ、ストレージデバイス(NVMe キャッシュ SSD を含む)、ネットワークカード等から、お客様に最適な組み合わせを選択することが可能です。

 

 

図 2:14世代 Power Edge ベースの VxRail 製品ラインナップ

 

 

VxRail の特徴

 

VxRail の特徴はいくつかあります。

1: 導入、増設がシンプル

  • プリインストールされた初期設定用 vSphere、vSAN 環境に、パラメータシート情報から作成した JSON ファイルを読み込む、またはウィザード形式で入力することでセットアップは 1 時間程度で完了。デプロイ時間の大幅な短縮を実現
  • 増設は同じ L2 セグメント上に新規ノードを設置すれば、既存 VxRail クラスタが新規ノードを認識し数クリック、10 分程度でノード追加が完了

2: サポートがシンプル

  • vSphere/vSAN から VxRail ハードウェア、更に Smart Fabric 対応 Dell EMC スイッチまで VxRail 担当サポートが一元窓口となり保守対応
  • VxRail 上の VMware 製品で問題エスカレーションが必要な場合でも、VxRail 担当サポートが VMware サポートと直接連携しお客様にご回答
  • 障害解析に必要な初期のログは、ハードウェア及び vSphere 情報とも vCenterの 「ログバンドルの作成」 から生成可能
  • プロサポートプラス契約で、VxRail アップグレードをサポート担当者がリモートからご支援可能。万一の障害発生の際にもサポートエンジニアがすぐに対応を開始可能なため安心

3: 運用がシンプル

  • VxRail HCI システムソフトウェアが vCenter と連携し、運用は vCenter から実施
  • vSphere、vSAN、各種ファームウェアがパッケージ化された VxRail HCI システムソフトウェアで、ワンクリックアップデート可能 (他社 HCI 製品と異なり、エンベデッド vCenter(vSAN データストア内に vCenter を配置)構成をした場合には、VCSA, PSC を含めてアップデートを実施可能)
  • Dell EMC の Smart Fabric 対応スイッチと組み合わせて利用すると、VLAN 変更など日常的なネットワーク運用も vCenter 経由で実施可能

 

特に “運用がシンプル” に関してですが、最新 VxRail 4.7 環境では vSphere 6.7/vSAN 6.7 ソフトウェアと BIOS, RAID カード、NIC 等のハードウェア用ファームウェアをパッケージ化した VxRail HCI システムソフトウェアを提供する事で、これまでお客様自身で行って頂いていた製品同士の組み合わせ検証を不要にしています。Dell EMC と VMware さんの共同開発だからこそ、vSphere/vSAN の最新アップデート、パッチ等のリリースを細かく追随し、各コンポーネントとの最適な組み合わせ検証を行った上でリリースします。最新パッケージを適用すると VxRail クラスタ全体が最新で最適なソフトウェア状態なり、運用での時間コスト削減に繋がるというメリットを享受できるのです。

 

図 3:運用での時間コストも削減

 

 

またアプライアンスなので、VxRail HCI システムソフトウェアのワンクリックアップデートやクラスタの増設や機器の入替等も vCenter 内の VxRail 管理用画面からシンプルなオペレーションで実行可能です。

 

図 4:vCenter に統合された VxRail の管理画面

 

VxRail と vCenter を通じた VMware ソフトウェアとのイイ関係

 

これらの連携を実現しているのは、VxRail クラスタを管理している VxRail Manager と vCenter との親密な関係にある事がカギとなっています。VxRail 4.5 以前の環境をご存じの方は、「あれ?なんで VxRail Manager の話が出てこない???」 と思っていらしたかもしれません。VxRail Manager  は VxRail クラスタ管理用の仮想マシンとして VxRail 4.7 環境でも存在していますが、vCenter プラグイン化したことでメインのユーザーインターフェースとして利用をする事が無くなりました。

vCenter プラグイン化の本質は他のアプリケーションとの連携を REST API 経由で可能にしたことです。このことで VCF と VxRail を繋いだ VCF on VxRail の構成が実現可能になりました。すなわちVCF のコンポーネントでもある vRealize OperationsvRealize Automation 等、vRealize Suite の製品群との連携も可能になったのです。

 

 

図 5:VxRail と vCenter の透過的な運用性

 

 

このシリーズの第 1 回で弊社吉田の説明もありましたが、VCF は vSphere、vSAN、NSX の各コンポーネントを標準化し、ライフサイクルマネージャー (以下、LCM) でシステム全体のライフサイクル管理を実施することで、SDDC としての自動運用を実現するソリューションです。標準化されたプロセスで仮想環境全体をデプロイし、仮想環境を安全かつセキュアにアップデートして行くことを自動化し、管理者が行っていたインフラレイヤーの組み合わせ検証にかける手間と時間から解放してくれます。SDDC ソフトウェアの自動インストールでは Cloud Builder が、設定及び LCM は SDDC Manager がこれらを実現します。

 

 

図 6:フルスタックインテグレーション

 

 

ですが、一つだけ、一般的な VCF 環境ではカバーできない部分があります。それがハードウェアのファームウェア管理です。ESXi をアップデートする際に使用しているサーバの BIOS バージョンの問題でそのままアップデート出来なかった、セキュリティホールの対応のために VIB をアップデートしようとしたが、物理 NIC のファームウェアバージョンのアップデートも必要になってしまった、このような経験をされた管理者の方も多くいらっしゃると思います。VCF on VxRail の環境はハードウェアからソフトウェアまで本当の意味でフルスタックなインフラの自動運用をご提供し、管理者の方の手間を極小化できるように致します。

 

 

VCF on VxRail のマネージメント全体像(図7)をベースに、具体的なコンポーネント管理をご説明致します。

 

図 7:VCF on VxRailのマネージメント全体像

 

VxRail Manager は vSphere、vSAN 及び HCI ハードウェアのデプロイ、構成、増設管理、ファームウェア管理、パッチ適用とアップグレードを行います。VCF on VxRail を構成する場合は、VCF のワークロードドメインは VxRail で言うところの外部 vCenter 構成となり VxRail Manager の管理配下ではなくなるところがポイントです。

VCF の管理ツールである SDDC Manager は vCenter と NSX を直接管理し VxRail クラスタの管理の為 VxRail Manager と API 連携致します。VCF としての LCM が発生した場合、SDDC Manager からみた vSphere、vSAN の管理は VxRail Manager を介して行われます。NSX や vCenter の管理はSDDC Manager が直接行います。これらの連携によって、SDDC Manager 経由でファームウェアを含めたライフサイクルマネジメントを実現しているのです。

 

まとめ

 

ここまでの説明で、VCF on VxRail を利用するメリットと構成概要が明確になってきたと思いますので、簡単に要点をまとめておきます。

  • VCF を使って自動で標準的な SDDC 環境をシンプルに短期間でデプロイ
  • VxRail 上に構築する事で、ファームウェアを含めたフルスタック なライフサイクル管理が可能
  • SDDC Manager が VxRail Manager と連携することで VCF on VxRail が動作

 

では実際に VCF on VxRail を構築、運用する方法について、どうなっているのでしょうか。

こちらを第 3 回目でご説明していこうと思います。

 

図 8:VCF on VxRailを実現するコンポーネント

 

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

<連載リンク>

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

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

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

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

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