Quantcast
Channel: VMware Japan Blog
Viewing all 861 articles
Browse latest View live

VMware NSXとTrend Micro Deep Securityで実現する仮想化セキュリティの最適化(11)

$
0
0

分散ファイアウォールと連携したマルウェア検出時の自動隔離

 

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

少し間が空いてしまいましたが、今回は Deep Security がマルウェアを検出した際に VMware NSX の分散ファイアウォールと連携して該当の VM を自動隔離する仕組みについてご紹介します。この連携はここ最近特に VMware Horizon の導入を検討されているお客様の多くでご利用をご要望されることが多いソリューションです。
ランサムウェアや標的型サイバー攻撃に対する対策の強化にあたり、インシデントが発生した段階でいち早く一次対処が可能となる点が採用のポイントになっています。

NSX 分散ファイアウォールによってユーザが利用する仮想デスクトップ環境のマイクロセグメンテーションを実装しておくだけでも、ランサムウェアや標的型サイバー攻撃の初期段階でよく見られる「横感染/拡散」を抑制することはできますが、さらに自動隔離を実装しておくことによって管理者の手を煩わせることなく感染した仮想デスクトップ(以下 VM)をネットワークから切り離すことが可能となります。また、あくまでこの「自動隔離」はハイパーバイザ上でのアクセス制御ポリシーによって行われますので、VM 側の vNIC には直接影響を与えないことも特徴です(ネットワークアドレスの変更や vNIC のステータスには変更はありません。)

以下にマルウェア検出時の自動隔離の仕組みと実装のポイントについて解説していきます。

 

Trend Micro Deep Security と NSX 分散ファイアウォールの連携イメージ

最初に Deep Security と分散ファイアウォールがどのように連携をするかのイメージを見ていきましょう。

  1. Deep Security Virtual Appliance(以下 DSVA)にて VM 上でのマルウェアを検出。DSVA からDeep Security Manager(以下 DSM)に不正プログラム対策イベントを検出
  2. DSM が不正プログラム対策イベントの検出をトリガーとして、NSX Manager に対して該当のVM への NSX セキュリティタグ情報を送信
  3. 該当の VM に対して NSX セキュリティタグが付与されることにより、予め設定されていた VM の NSX セキュリティグループが変更されることによって適用されるファイアウォールポリシーが変更されて、ネットワークアクセスが制限される

マルウェアを検出して NSX セキュリティタグを付与するまでは Deep Security の役割、実際の VM のアクセス制御を行うのは VMware NSX の役割となります。また、NSX セキュリティタグが付与された VM は vCenter 上からも確認することが可能です。

 

自動隔離を実現するために必要な設定

マルウェア検出時に設定しておくべきポイントは大きく以下の 3つがあります。

  • NSX セキュリティグループの作成
  • NSX 分散ファイアウォールの設定
  • Deep Security での NSX セキュリティタグ付与の設定

ここではすでに VMware NSX と Deep Security のエージェントレス型セキュリティ対策に必要な設定は完了している前提で上記の3つのポイントについて解説していきます。詳細の設定手順を確認したい方は、以下のインテグレーションガイドを参照してください。

VMware NSX & Trend Micro Deep Security インテグレーションガイド
<ダウンロード先>
Trend Micro Deep Security サポートウェブ
VMware テクニカルリソースセンター

 

【NSX セキュリティグループの作成】

エージェントレス型セキュリティ対策の実装が完了していれば、VM をグルーピングするためのセキュリティグループの設定はすでに行われているはずですが、以下の設定を加えておく必要があります。

  1. 通常運用時に所属しているセキュリティグループに対する NSX セキュリティタグが付与された VM を除外する設定の追加
  2. NSX セキュリティタグが付与された VM が所属するセキュリティグループの作成

NSX セキュリティグループの特性として、同一 VM が複数のセキュリティグループに参加することができてしまうため、1. 側で除外設定をしておかないと NSX セキュリティタグが付与された際に両方のグループに所属することになり、正しく隔離動作が行われなくなります。
また、2. の隔離用のセキュリティグループは正常時は VM が所属しないグループとなります。(設定の方法は上記に限らず設定はできると思いますので、環境に合わせて設定をしていただければと思います。)

 

【NSX 分散ファイアウォールの設定】

実際にマルウェアを検出した際に自動隔離するためには、先ほど設定をしたセキュリティグループを利用して隔離用のファィアウォールルールを作成する必要があります。
ここで、分散ファィアウォールにおけるセキュリティポリシー、グループの関係を整理しておきましょう。

分散ファイアウォールの設定は通常のネットワーク型ファィアウォールと同様で、送信元や送信先を IP アドレス(または IP アドレス)以外の仮想マシンやセキュリティグループなどをオブジェクトとして利用することでよりシンプルなルール設定が可能となっています。
実際には以下のようなファィアウォールルールを設定することになります。

この例ではルール ID #4/#5 に隔離用グループのアクセス制御ルールを記載しており、Incoming、Outgoing の通信を完全に遮断する形となっています。運用要件に応じて、隔離時にも通信が必要なトラフィックがある場合には適宜ルールをカスタマイズ、追加して対応することができます。特に VMware Horizon 環境の場合、Horizon Connection Server とのコネクションが切断されてしまうことで隔離した VM が削除されてしまうことがあり、そういった際には隔離グループと Horizon Connection Server との通信を許可するルールを設定しておくことも有効です。

また、自動隔離とは直接関係はしませんが、仮想デスクトップ環境において利用する場合、現在のクライアント PC に導入されるアプリケーションの多くは、サーバとの通信を行うのがほとんどで、クライアント間の Peer to Peer の通信が必要なことはありません。クライアント環境の脅威で特に留意が必要なランサムウェア感染時の横拡散や標的型サイバー攻撃の着弾を受けたクライアントからの攻撃者の探索活動に対しては、ルールID #3 のような仮想デスクトップ間の通信をブロックするルールを設定しておくことで被害の拡大を抑制することが可能となります。IP アドレスベースではなく、セキュリティグループをファイアウォールルールのオブジェクトとして指定できることで同一ネットワークにある仮想デスクトップ同士でも必要なセキュリティポリシーを柔軟に適用できるところは NSX 分散ファイアウォール活用の大きなメリットではないかと思います。

 

【Deep Security での NSX セキュリティタグ付与の設定】

あとは Deep Security 側で不正プログラム対策イベントが検出された際に NSX セキュリティタグを NSX Manager へ送信するために必要を設定しておく必要があります。
DSM のコンソールにアクセスをして、自動隔離を行いたい VM(正確には自動隔離を行いたい NSX セキュリティグループに割り当てた NSX セキュリティポリシー)に紐づく Deep Security ポリシーを選択します。

不正プログラム対策の[詳細]タブより、NSX セキュリティのタグ付けを有効化する設定を行います。
NSX セキュリティタグはすでに用意されている 3つのタグのうちどれを利用していただいても問題ありません。(high / medium / low のどれを選択しても挙動は一緒です。)
また、自動隔離された後に、フル検索を手動で実施した際に新たなウイルスを検出しなかった場合に NSX セキュリティタグを自動的に削除(隔離グループから通常のグループへの復帰)したい場合には、[この後の不正プログラム対策が不正プログラム検出イベントが生成されずに完了した場合、以前に適用された NSX セキュリティタグは削除されます。]にチェックボックスを入れてください。(もちろん、vCenter から該当 VM の NSX セキュリティタグを手動で外すことも可能です。)

また、DSM と DSVA との間ではデフォルト 10分に 1回のハートビートで相互の状態確認を行っています。不正プログラム対策イベントはハートビートのタイミングで DSVA から DSM へ通知されるため、このままだと感染検出時に即時に隔離を行うことができません。そのために、DSVA がホスト上の VM で不正プログラム対策イベントを検出した場合に、ハートビートのタイミングを問わず、即時に DSM にイベントを通知する設定を行う必要があります。
この設定は DSM のコンソールから設定はできないため、OS上でコマンド実行を行っていただく必要があります。(以下は Windows OS で DSM を構築した場合のコマンド例)

DSM のプロセスの再起動が発生します。
また、DSVA に設定を反映することが必要なため、この後に必ず DSVA に対するポリシーの再配信を行ってください。(設定反映のためのポリシー配信のため、各 VM に対するポリシー配信ではないことを注意)

上記の一連の設定を完了すれば、Deep Security の不正プログラム対策イベントを起点とした自動隔離を行うことができるようになります。

 

 

まとめ

いかがでしたでしょうか。
Deep Security と VMware NSX の連携は単純にエージェントレスでのセキュリティ対策を実現するだけではなく、インシデント発生時のオペレーションの自動化を図るためにも利用することができます。本編でも記載をしましたが、NSX 分散ファイアウォールをうまく利用することで通常時でもランサムウェアの拡散や標的型サイバーいかがでしたでしょうか攻撃着弾時の横感染のリスクを低減できますし、いざとなったときにさらに強固な隔離用ファイアウォールルールを自動適用することができます。
みなさんが当たり前に使っているファイアウォール、ウイルス対策ですが、Deep Security とVMware NSX の連携をうまく活用していただくことでセキュリティレベルの向上の運用性の向上の両立を図っていただけるのではないかと思います。
ぜひ、お試しください!

 

 

執筆者:
トレンドマイクロ株式会社
セキュリティエキスパート本部
パートナービジネスSE部 パートナーSE2課
栃沢 直樹(Tochizawa Naoki)

 

【VMware NSXとTrend Micro Deep Securityで実現する仮想化セキュリティの最適化】

    1. Horizon インスタントクローンにも適用可能!仮想デスクトップ環境にフィットしたセキュリティ対策
    2. VMware NSX + Deep Secuirty連携によるエージェントレスセキュリティとは?
    3. VMware NSX + Deep Security連携にかかわるコンポーネントと基本構成
    4. VMware NSXとDeep Securityのユースケースと実現できることとは?
    5. エージェントレス型ウイルス対策のアーキテクチャ(1)
    6. エージェントレス型ウイルス対策のアーキテクチャ(2)
    7. エージェントレス型による侵入防御/Webレピュテーションの実装
    8. エージェント型とエージェントレス型の使い分けのポイント
    9. コンバインモードの正しい理解と知っておきたいこと
    10. エージェントレス型セキュリティ環境におけるWindows 10 Creators Updateの対応
    11. 分散ファイアウォールと連携したマルウェア検出時の自動隔離

 

The post VMware NSXとTrend Micro Deep Securityで実現する仮想化セキュリティの最適化(11) appeared first on Japan Cloud Infrastructure Blog.


vROps 6.7は初心者に優しい!#5

$
0
0

5回目:vSAN運用管理者にはvROpsは欠かせないツール

— Back Number —

#1:仮想基盤のパフォーマンスは使用率だけでは図れない
#2:アラートからブレイクダウン
#3:仮想マシンのリストはカスタムビューで
#4:6.7バージョンはメトリックの活用がポイント
#5:vSAN運用管理者にはvROpsは欠かせないツール

日本ヒューレット・パッカード株式会社の中川明美です。
5回目は「vSAN運用管理者にはvROpsは欠かせないツール」です。

vSAN監視のために、vROpsとの連携が強化されていますね。6.7からは「vCenter Server の vRealize Operations Managerプラグイン」が提供されています。
先日弊社教育サービスに、パートナー様から、「エンドユーザー様からのご依頼により、vROpsの知識を身につけたい」とお問い合わせがありました。
「vSANの運用監視のためにvROpsの活用方法をお知りになりたいのでしょうか」とお尋ねしたところ、「vSAN前提で、vROpsの設計から学習したい」というご要望でした。
vSANの運用監視をされるのはエンドユーザー様ですから、vSANの導入が増えるにしたがい、vROps連携の依頼も増えるのかもしれませんね。
vROps 7.0からはVMware Cloud on AWSと連携することも可能です。連携する対象が増え、この数年vROpsの啓もう活動をしてきた私には楽しい状況です(笑)。

vCenter ServerでもvSANの基本的なパフォーマンスメトリックを監視することはできます。vSANのパフォーマンスメトリックは他のメトリックとは異なり、vCenter Serverに保存されず、 vSANデータストアに存在するオブジェクトとして格納されます。データを表示できる時間は1時間から24時間、保持日数は90日間です。vROpsのデータ履歴の保持期間はデフォルト6か月です。

KB:How to configure Data Retention in vRealize Operations Manager 6.x and later (2147600)

加えて、vROpsはvCenter Serverにはないメトリックの提供、収集したデータのカスタマイズ表示が可能です。

先に、「vCenter Server の vRealize Operations Managerプラグイン」からご紹介します。

◆vCenter Server の vRealize Operations Managerプラグイン◆

vSphere Clientから、「VMware vROps Client Plugin」を確認できます。

ホームまたはメニューから、「vRealize Operations」を選択します。

プラグインを使用する場合は、この画面から「インストール」または「既存インスタンスの構成」を選択し、進めます。完了後、表示されるまで多少のタイムラグがあります。vSANはvCenter Serverより数分遅れて表示されます。

<vCenter ServerのvRealize Operations Manager プラグインのドキュメント>
詳細は次のドキュメントを参照ください。
https://docs.vmware.com/jp/VMware-vSphere/6.7/com.vmware.vsphere.vrops/GUID-57D6EFBD-3FD2-4EDC-A754-594F7AFE546E.html

 

画面右側の「クリック リンク(赤枠)」メニューから、vSANの画面に切り替えます。また「vRealize Operations(緑枠)」リンクをクリックすると、新規タブにvROpsのログイン画面が表示されます。

< vSANの概要 >

すべてのvSANクラスタを対象に、「最低限このメトリックのみ確認しておけばよいでしょう」というデータが表示されています。アラートの「詳細表示 (赤枠) 」をクリックすると、このプラグイン内のアラートリストの画面に遷移します。

< vSANのクラスタ ビュー >

「クラスタの変更 (赤枠)」から、各vSANクラスタのデータへ切り替え、1つのクラスタのメトリックを確認することができます。
1点気になるのが、「最終更新日(緑枠)」の時刻はJST (Japan Standard Time) ですが、各メトリックの時刻はUTC (Universal Time, Coordinated) で表示されているようです。黒いポップアップはグラフの一番右にマウスを合わせ表示しています。
下図では、最終更新日は12:40 PM、ポップアップの時刻は3:26です。9時間ほどの差があります。この時刻はHost Clientで確認するUTCの時刻とほぼ一致しています。
「vSANの概要」も合わせ、ここは注意点かもしれません。

< vSANの アラート >

vSANクラスタ内のアラートを表示します。

ここからは、vRealize Operationsです。

◆vRealize OperationsのvSANダッシュボード◆

vROps 6.7では事前に提供されるvSANに関するダッシュボードが4つあります。
ここでは、「vSAN運用概要」と「vSANへの移行」の2つのダッシュボードを取り上げます。

< vSAN運用概要 >

vSANのプラグインはvSANに特化したデータ表示ですが、vROpsは一画面でコンピュータリソースのデータも表示されます。CPUやメモリリソースも同時に確認できます。
ディスクデータの赤色の点線枠は現在の値です。現在値と履歴トレンド (傾向) がわかるのは便利です。
ディスクに関する値はTB (テラバイト) で表示されています (青色の点線枠) 。大容量のサイズを構成していない場合は、単位はGB (ギガバイト) の方が把握しやすいかもしれませんね。

ダッシュボードの「ウィジェットの編集 (鉛筆のアイコン) 」をクリックし、編集画面から表示する単位を変更することができます。カスタマイズにはAdvanced以上のエディションが必要です。

この環境のディスクサイズは少量のため、単位をGBに変更したことで管理しやすくなりました。事前に提供されるダッシュボードもカスタマイズするとより使いやすくなりますね。

< vSANへの移行 >

非vSAN (従来の) データストアまたはvSANデータストア内の仮想マシンのストレージメトリックを監視することができます。以前のバージョンの「vSANデプロイの最適化」ダッシュボードと比べてシンプルになりました。仮想マシンのディスクパフォーマンスを考慮しつつ、非vSANデータストアとvSANデータストアとの間で仮想マシンの移行の検討をすることができます。

◆ご紹介ドキュメント◆

このBlogを執筆するにあたり、参考にした英語のドキュメントを共有します。

◆まとめ◆

vROpsのバージョンが上がると、vSANとの連携が強化されますね。
vSANの運用管理は、Web Clinet、vSphere Client、Host Clientからもできますが、仮想基盤全体のメトリックの集約と分析にはvROpsの出番です。パフォーマンスはコンピュータリソースの視点も必要です。vROpsを使用して、コンピュータリソースが必要なのか、ディスク容量が必要なのかを把握できます。さらにvRealize Log Insightも準備すれば、重要なログインベントメッセージの検索が容易になります。トラブルシューティング時は安心ですね。先にご紹介したvSANのドキュメント内にLog Insightのデモがあります。ぜひご確認ください。
こちらでご紹介した内容が、みなさんのお役に立てたなら幸いです。

The post vROps 6.7は初心者に優しい!#5 appeared first on Japan Cloud Infrastructure Blog.

VMware NSXとTrend Micro Deep Securityで実現する仮想化セキュリティの最適化(12)

$
0
0

Cross-vCenter NSX 環境における Deep Security の構成ベストプラクティス

 

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

 

私の役割の 1つとして、お客様毎の VMware 仮想環境とお客様の要望に対して、Deep Security をどのように導入するのが最適かをご提案させていただく、というものがあります。

その中で 2018年にいくつかのお客様からご相談をいただいたのが、Cross-vCenter NSX 環境における Deep Security の導入についてでした。

データセンターが複数にまたがっている場合には、vCenter Server の Block もデータセンター毎に配置されることが多く、Cross-vCenter NSX を利用して仮想マシンの一元管理と障害時のスムーズなデータセンター間移行を実現したいというニーズが増えてきているようです。また、同一データセンター内でも管理上 vCenter Server を分けているケース(開発環境と本番環境の分割管理)もあり、運用フェーズに応じて仮想マシンを移行していきたいというケースもあるようです。

 

そこで今回は Cross-vCenter NSX 環境において Deep Security を導入する場合のユースケースをご紹介したいと思います。

 

Cross-vCenter NSX 環境について改めて整理してみる

まず、Cross-vCenter NSX 環境について改めて整理をしてみましょう。

  • 同一の Platform Services Controller(PSC)配下に各データセンターの vCenter Server が配置され、各 vCenter Server が同一 SSO ドメインに属していること。
    vSphere 6.7 の場合は、Embedded PSC もサポートされていますが、Deep Security との連携とは直接関係がないため、言及は割愛しています。)
  • 各 vCenter Server で拡張リンクモード設定が行われていること。
    拡張リンクモードにより複数の vCenter Server Block のインベントリ情報を一元管理することができるようになります。
  • Cross-vCenter NSX 設定により NSX サービスも vCenter Sever を跨いだクラスタで一元管理できること。
    Cross-vCenter NSX 設定時に vCenter Server に紐づく NSX Manager のどちらをプライマリロールとするかを選択する必要があります。
    ※ ネットワークの拡張においては、各 vCenter Server Block のクラスタ間のオーバレイネットワークが同一セグメントで拡張されるようにする必要があります。
    ※ 物理的にデータセンターが分かれている場合は、ユニバーサル分散論理スイッチを展開して L2 ネットワークを拡張する必要があります。同一データセンターで各 vCenter Server 配下のクラスタ上に展開されている分散スイッチ上のネットワークアドレス体系が同一の場合(同一のネットワークスイッチ群に接続されている)場合には、ユニバーサル論理スイッチの展開は不要となるでしょう。

 

Cross-vCenter NSX 環境における Deep Security 構成のベストプラクティス

ここからはサンプルのデータセンター構成(2つのデータセンターにそれぞれ vCenter Server、NSX Manager が構築されている Cross-vCenter NSX 環境)で Deep Security を導入する際のベストプラクティスを解説していきたいと思います。
Cross-vCenter NSX 環境で Deep Security を導入する場合には、プライマリとして動作するデータセンター(以下の図ではデータセンター A)に Deep Security Manager(DSM)を配置することを推奨します。

Cross-vCenter NSX 環境に限らず、Deep Security と VMware NSX との連携にあたっては DSM、vCenter Server、NSX Manager の連携が非常に重要となります。
以下のような三角形のようなイメージでのコネクションにより、インベントリ情報の共有、ポリシー連携などが実現されます。
(ポリシー連携の詳細については、第6回ブログをご参照ください。)Cross-vCenter NSX 環境で DSM を連携する際には、データセンター A の vCenter Server / NSX Manager、データセンター B の vCenter Server / NSX Manager それぞれと接続設定をする必要があります。(拡張リンクモードで接続されているとしても、DSM はあくまで vCenter Server Block がそれぞれ独立して存在するものとして連携します。)
連携設定後、DSM の管理コンソールからは vCenter Server Block が両サイト分表示されることになります。

サンプル構成のように、DSM を片方のサイトに設置して、両サイトの vCenter Server 配下の仮想マシンを統合的に保護することによって、データセンター A からデータセンター B へ vCente Server 跨ぎで Enhanced vMotion した場合でも自動的に Deep Security のセキュリティ保護を継続することができます。
実際には、Enhanced vMotion した際には移行先の vCenter Server 上では新たな仮想マシンが生成されたように見えるため、その仮想マシンに新たなUUID が付与されたと認識して、NSX セキュリティポリシーが自動的に適用されて、合わせて Deep Security ポリシーも有効化される動作となります。
(Deep SecurityのポリシーとNSXセキュリティポリシーの関係については、第6回ブログをご参照ください。)

ここで、「なぜ、DSM を vCenter Server と同様に両サイトに置かないのか?」という疑問が出てくることでしょう。
その理由は、DSM がその管理配下に入る Deep Security Agent(DSA)、Deep Security Virtual Appliance(DSVA)をどのように管理するかということに関係してきます。

Deep Security では DSA、DSVA の保護に問わず、仮想マシン毎に割り振るべきポリシーを管理しており、その仕組みに ”フィンガープリント” を利用しています。
DSA または DSVA の保護対象になる仮想マシンは、DSM の管理配下で有効化処理をされた時点で仮想マシン毎に固有のフィンガープリントを発行され、一意に管理されます。(コンバインモードで保護されている仮想マシンは、DSA と DSVA 双方のフィンガープリントを保持します。コンバインモードについての詳細は、第9回ブログをご参照ください。)フィンガープリントを保持することにより、対象の仮想マシンは必ず一意の DSM に紐づくことが保証され、vMotion などにより他の環境に移動した際にも、勝手に他の DSM の管理下に入ってしまうことを防ぐためにセキュリティ的なプロテクトをかけることができます。(フィンガープリントは、仮想マシンに対する無効化処理を行い、なおかつ、DSA の場合にはエージェントが保持しているフィンガープリントを手動でリセットしない限り削除されません。)

上記のように、Deep Security は VMware vSphere / VMware NSX の仕組みとは別に独自の仕組みによって、DSM と保護対象である仮想マシンをセキュリティ保護する DSA / DSVA との間で各仮想マシンを一意に管理しているため、Cross-vCenter NSX 環境で DSM を利用する場合には、DSM はどちらかのサイトにだけ配置して、各 vCenter Server、NSX Manager と連携をすることが運用面からも最適と考えられます。

 

vCenter Server Block に対応して DSM を配置した場合の留意点

もし、DSM をデータセンター B にも配置して、vCenter Server Block と対になる形で構成したい場合には、前述の通り、Deep Security は VMware vSphere / VMware NSX の仕組みとは別にフィンガープリントにより DSM と DSA が一意に紐づいていることから、Enhanced vMotion を実行する仮想マシンに DSA がインストールされている場合、移行先の vCenter Server 配下のクラスタで有効化されたとしても、DSA のフィンガープリントが移行元の DSM となっているため、正常に保護を行うことができなくなります。正常に有効化をするためには、Enhanced vMotion 実行後に DSA のリセット処理を行う必要があります。この処理は、仮想マシン上から手動にて実行する必要があります。

また、いくつかの機能については、DSM 側で情報を保持して機能を提供しているため、以下の制約が発生します。

  • 各サイトにおいて、それぞれ同一の DSM 上のポリシー、vCenter Server / NSX Manager の NSX セキュリティポリシー / セキュリティグループを設定しておく必要がある。
  • 推奨設定の検索の結果、変更監視のベースラインが移行元 DSM から移行先 DSM へ引き継がれない。(推奨設定の検索、ベースラインの新たに構築を実施する必要がある。)

 

Cross-vCenter NSX 環境で Deep Security 連携する場合の制約事項

ベストプラクティスに則った構成であっても、いくつかの制約事項があります。

  • 移行元の vCenter Server 配下で DSA が有効化されていなかった仮想マシンが、Enhanced vMotion した場合には、移行先の vCenter Server で起動したタイミングで、DSA の有効化が自動的に行われます。(NSX セキュリティポリシーによって、新しい UUID を付与された仮想マシンが起動したと認識して、Deep Security ポリシーを含めたサービス適用を行うため。)
  • DSVA で変更監視を行っている場合、変更監視のベースラインマッチングを行うエージェントデータベースを移行できないため、ベースラインを新たに構築する必要がある。

 

少し複雑な内容だったかもしれませんが、ご理解いただけましたでしょうか?
基本的には、以下の点を抑えて設計をいただければ、正しい設計をいただけるのではないかと思います。

  • DSM は vCenter Server / NSX Manager とそれぞれの Block 毎に連携設定を行う。
  • DSM と DSA / DSVA は仮想マシン毎にフィンガープリントによって一意に紐づいている。
  • 構成に応じた制約事項、留意事項があることをあらかじめ理解しておく。

 

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

 

【VMware NSXとTrend Micro Deep Securityで実現する仮想化セキュリティの最適化】

    1. Horizon インスタントクローンにも適用可能!仮想デスクトップ環境にフィットしたセキュリティ対策
    2. VMware NSX + Deep Secuirty連携によるエージェントレスセキュリティとは?
    3. VMware NSX + Deep Security連携にかかわるコンポーネントと基本構成
    4. VMware NSXとDeep Securityのユースケースと実現できることとは?
    5. エージェントレス型ウイルス対策のアーキテクチャ(1)
    6. エージェントレス型ウイルス対策のアーキテクチャ(2)
    7. エージェントレス型による侵入防御/Webレピュテーションの実装
    8. エージェント型とエージェントレス型の使い分けのポイント
    9. コンバインモードの正しい理解と知っておきたいこと
    10. エージェントレス型セキュリティ環境におけるWindows 10 Creators Updateの対応
    11. 分散ファイアウォールと連携したマルウェア検出時の自動隔離
    12. Cross-vCenter NSX 環境における Deep Security の構成ベストプラクティス

 

The post VMware NSXとTrend Micro Deep Securityで実現する仮想化セキュリティの最適化(12) appeared first on Japan Cloud Infrastructure Blog.

vSphere 6.7 / vSAN 紹介ウェビナー開催のお知らせ

$
0
0

VMware パートナーチームの内野です。

3/13 (水) のお昼の時間に、下記のオンラインセミナーを開催させて頂きます。インターネットに接続出来ていれば、日本全国はもちろん、海外からでも参加できる非常にお手軽なオンラインセミナーです。

去年の vFORUM でも非常に人気のセッションだった vSphere 6.7 の最新機能紹介とやはり、お客様やパートナー様からのお問い合わせが非常に多い VMware の HCI : vSAN に関するご紹介をさせて頂きますので、是非、多くの皆様にご参加頂ければと思っております。

 

vSphere & vSAN オンラインセミナー

~ 仮想化システムの運用負荷軽減に効く!! vSphere & vSAN 最新機能と活用法をご紹介


 

本オンラインセミナーでは、vSphere や vSphere に一番最適な HCI である vSAN に関して製品のご紹介から利用用途・導入事例等様々な情報をお届けさせて頂きます。

対象 : パートナー企業様、エンドユーザー様
※競合企業、もしくは対象外と判断させていただいた方は、ご遠慮いただく場合がございます。

主催 : ヴイエムウェア株式会社

日時: 2019年 03 月 13 日(水) 12:00-13:00

費用: 無償

申し込み : こちらよりお申込み下さい

■ セミナー目次 :
=============

12:00-12:25
—————–
vSphere 6.7 What’s New – 進化した vSphere 6.7 の最新機能をご紹介

講演者 : ヴイエムウェア株式会社

(セッション概要)
今回のリリースの特徴には、管理の大幅な簡素化と効率化、組み込み型の包括的なセキュリティ、より多くのワークロードへの対応強化、ハイブリッド クラウド関連機能の強化があります。本セッションでは、それらを実現する為に実装された VMware vSphere 6.7 の新機能と拡張された機能について解説します。

12:25-12:50
—————–
vSAN 概要紹介

講演者 : ヴイエムウェア株式会社

(セッション概要)
サーバにコンピューティング機能とストレージ機能を統合したシンプルな構成の仮想化基盤として、ハイパーコンバージドインフラ(HCI)の普及が急速に進みつつあります。仮想化システムの運用管理の負荷にお困りのお客様や、仮想化システムの更新を検討中のお客様に最適な VMware の HCI : vSAN に関して、概要および利用方法をご紹介させて頂きます。

12:50-13:00
—————–
Q&A


 

では、当日のオンラインセミナーでお会いできることを楽しみにしております。

また、今後、定期的に vSphere や vSAN 等のオンラインセミナーを行う事を計画しております。

今後、取り扱って欲しい内容や VMware のオンラインセミナーで発表してみたい等のご意見がございましたら、お気軽にご意見を頂ければ幸いです。

 

VMware 内野

The post vSphere 6.7 / vSAN 紹介ウェビナー開催のお知らせ appeared first on Japan Cloud Infrastructure Blog.

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

$
0
0

Part1:「VMware Cloud Foundation (VCF) 」 をご存知ですか?

 

ー Back Number ー

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

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

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

#4 VCFはHPE Synergy との連携に優れている

 

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

昨今、パブリッククラウドやプライベートクラウドの登場を背景に、「従来型のシステムを将来に向けてどのように変化させていけばよいのか」といった相談が増えてきました。こういった性質の異なるサービスのメリットをうまく組み合わせた「ハイブリッドクラウド」というワードもメディアで取り扱われるようになり、都市部では有志によるハイブリッドクラウド勉強会なども開催されるようになってきています。

 

そんなハイブリッドクラウドを実現する1つの手段として、「VMware Cloud Foundation ™」製品があります。“VCF”(ヴイ・シー・エフ)と略されるこの製品はvExpertでもある私のイチオシであり、今後もVMwareのオンプレミス製品をお使いの方はもちろん、「VMware CloudTM on AWS」といった話題のクラウドサービスをご検討の方も理解しておかなければならない“必須科目”です。

 

HPEはVCFにおいて日本のみならずグローバルにて協業を進めており、以下のような記事も発表しております。

今回は、HPE Synergy上でVCFを検証した結果も含め、4回に分けてVCFのご紹介を行っていきます。

ご参考記事:

HPE、VMware Cloud Foundation認定のハイブリッドIT基盤を発表(ASCII.jp)

https://ascii.jp/elem/000/001/666/1666586/

 

対談 システムの自律化がクラウドの未来を切り開く(日経XTECH)

https://special.nikkeibp.co.jp/atclh/NXT/18/hpe1005/

 

◆ VMware Cloud Foundation (VCF)とは?◆

 

早速ですが、VCFを一言でいうと「ハイブリッドクラウドを実現するための製品」です。

 

VMware Cloud Foundationの“ファンデーション”は化粧品のそれと同じで「土台」や「基盤」といった意味があります。つまり、VCFはVMware Cloudのベースとなっていることがわかります。意外に知られていませんが、実は先ほど挙げたVMware Cloud on AWS もVCFをベースに動いています。

 

“クラウド”という言葉が付いていますが、VCFはなんとオンプレミス環境でも利用することができます。つまり、VCFはオンプレミスでもパブリッククラウドでも利用することができる、共通技術(アーキテクチャー)なのです!!

 

―――オンプレミスでもパブリックでも?あれ、このフレーズ最近よく耳にしますよね?

はい。「ハイブリッドクラウド」です。

 

 

◆ VCFの構成要素 ◆

 

冒頭ではVCFのことを「製品」と書きました。ただ「共通技術(アーキテクチャー)」とも表現しています。しかもVMware Cloud on AWSもVCFで動いている!?

――― 一体どういうことでしょう。

 

まず、VMware Cloud on AWSについてですが、これはAWSのべアメタルサーバーにVCFソフトウェア(製品)をインストールしてユーザーに提供するフルマネージド型のクラウドサービスです。

 

理解を深めるために、より身近な製品(コンポーネント)まで掘り下げてみましょう。VCFにはよく耳にする次の製品が組み込まれています。

 

 

◆ キーとなるのは 「VMware SDDC Manager」 ◆

あれ、1個聞き慣れない製品が混じっていますね・・・「VMware SDDC Manager」。これは何者でしょう?

 

「VMware SDDC」も呼ばれる、vSANやNSX・vRealizeまで導入したソフトウェアデファインドなVMwareインフラ。これを実際に構築・運用することを考えてみてください。HCI(Hyper Converged Infrastructure)であるvSANを使っていますし、一見外部ストレージ要らずでシンプルなアーキテクチャーに感じますが、実際のところはどうでしょう?

よくよく考えてみると、面倒を見なければいけないものがものとても多い。大まかに図にしただけでもこれだけのものがあります。

 

 

これら1個1個の四角アイコンは、ハードウェアもソフトウェアもそれぞれ“バージョン”を持っています。バージョンがあるということは「バージョン管理」をしていかなければならない―――。

 

このバージョン管理を手動で行っていくのは、日常的にかなりの手間と時間が掛かります。芋づる式のバージョン互換性を紐解きながらバージョンアップしなければいけませんし、トラブルなく進めるには事前検証・調査も必要です。それなりの規模になればトラブル無しは当たり前。いかにダウンタイムを最小限に留められるかを求められる運用管理者も多いのではないでしょうか。もし、事前の調査不足や検証不足などでバージョンアップが途中で失敗したらそこでトラブルシューティングをしなければならず、更に時間を要してしまいます。損ばかりの悩ましい問題です。

※バージョンは一例です

 

vSphereはもちろん、vSAN, NSX, vRealizeをきちんと導入してソフトウェアデファインドなSDDCインフラを目指したいけど、運用が大変―――。

 

これを解決するのが「VMware SDDC Manager」です。

 

VMware SDDC Manager はVCFアーキテクチャー環境専用の運用管理ツール。VCFを構成するvSphere, vSAN, NSX, vRealizeといった各コンポーネント(ソフトウェア)の「導入」「構成」「プロビジョニング」「パッチの適用」といった一連のライフサイクル管理を自動化して運用を大幅にラクにするツールです。

 

「ライフサイクル管理??」

 

このメリットは今後本連載を通じて一つずつご紹介していきたいと思いますが、少しだけスクリーンショットをお見せします。

 

まずは導入(セットアップ)フェーズ。

既にここから自動化です。vCenter Serverのインストールはもちろん、仮想スイッチやクラスタ構成・vSANのセットアップ・設定もすべて自動。しかも、VMware社の開発エンジニアの考える「うちの製品をこう設計・構築して欲しい」という姿―――。つまり“メーカーの理想形”(*) の環境にセットアップされます。

 

*「VMware Validated Design」と呼ばれています

 

自動セットアップ画面 「Bringing Up the SDDC」

自動セットアップが終わると、VCF専用の管理画面「VMware SDDC Manager」にアクセス可能になり、ここで一連のライフサイクル管理を行っていきます。

 

VMware SDDC Manager:Dashboard

 

今回はVCFの概要についてご紹介しました。

次回は、VCFがどのようなお客様にとってメリットがあるのかをご紹介いたします。

 

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

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

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

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

 

The post VMware Cloud Foundation でハイブリッドクラウドへ踏み出そう appeared first on Japan Cloud Infrastructure Blog.

Microsoft SQL や Exchange サーバーを VMware vSAN で稼働させるリファレンスアーキテクチャのご紹介・vSphere / vSAN オンラインセミナー実施のお知らせ(2019年04月)

$
0
0

VMware パートナーチームの内野です。

皆さまは、システムを構築する時に、例えば、Microsoft SQL サーバー専用の環境・Exchange サーバー専用の環境の様に各システムを個別に構築しておりませんでしょうか。

もちろん、SQL サーバーの負荷が高くなってしまった時に Exchange サーバー側への影響が発生してしまうのではないか。等のご心配も多くあるのではないかと思っております。

VMware vSAN は、Oracle、SAP、MS SQL サーバー、Exchange 等の様々なビジネスクリティカルなアプリケーションを混在させて稼働させることにより、クラスタの統合が行えることができるスケーラビリティを備えています。

クラスタの統合を行う事により、運用管理負荷の減少・柔軟性の向上・ハードウェアリソースの有効活用により、結果としてトータルコストの削減に役立ちます。

今回、ご紹介する “Mixed Workloads on VMware vSAN All-Flash” では、混在するワークロードがある様な環境において、インフラ管理者が VMware vSAN をどの様に構成するべきかの助けになる構成ガイドとベストプラクティスが記載されております。

 

 

また、こちらのデザインガイドの中には、よくお問い合わせを頂くパフォーマンスに関するテスト結果や Disk Group やキャッシュディスクが破損 (Fail) した場合のパフォーマンス結果の記載もございますので、ご興味がある方はぜひ、ご一読下さい。

■ 例 : 単一の vSAN データストアグループ上で SQL Server Always On Availability Groups と Exchagne Server Database availability groups を同時に稼働させた際のパフォーマンスデータ

■ 例 : Disk Group 障害時 (18:40 前後) の SQL サーバーの動作に関するテスト結果

 

本ガイドの中には、バックアップに関する影響等に関しても記載がされております。詳しくは、是非、”Mixed Workloads on VMware vSAN All-Flash” からご興味のある内容をご確認頂ければと思います。なお、本ブログは、下記 URL ブログの内容を翻訳・抜粋・補足を追記させて頂いたものとなります。不明点に関しては、下記ブログも合わせてご確認下さい。

Mixed Workloads on VMware vSAN for Microsoft SQL Server and Exchange

 

なお、上記でもご紹介している VMware vSAN に関して、2019 年 4 月にオンラインセミナーを実施させて頂くこととなりました。

(注意 : 上記、Microsoft SQL や Exchange サーバーを稼働させる際のリファレンスアーキテクチャーの話はオンラインセミナーでは含まれておりませんのでご注意下さい)

今回は、下記の 2 つのオンラインセミナーを実施させて頂きます。

4/19 日の “vFORUM 2019 プレイバック!基礎からわかる HCI 入門” では、HCI 導入の背景や VMware vSAN の概要・特徴等を解りやすくご紹介させて頂きます。vFORUM 2019 のブレイクアウトセッションでも非常にご好評を頂いたセッションンになっております。

4/24 の “【リアルタイム実況!!】 1 時間で vSAN 初期構築はどこまできる!?” では、オンラインセミナー中に VMware のインターネット上のハンズオン環境を使って、実際に VMware vSAN の構築作業を行い、その様子をオンラインセミナー経由で中継させて頂きますので、実際の構築作業を行いたい方向けの内容となっております。

 

vFORUM 2018 プレイバック! 基礎からわかる HCI 入門

vSphere / vSAN オンラインセミナー 2019#2

 

対象 : パートナー企業様、エンドユーザー様
※競合企業、もしくは対象外と判断させていただいた方は、ご遠慮いただく場合がございます。

主催 : ヴイエムウェア株式会社

日時: 2019年 04 月 19 日(金) 12:00-13:00 (11:50 から受付開始)

費用: 無償

申し込み : こちらよりお申込みください。

講演者 : ヴイエムウェア株式会社 奥村 奈緒美

■ セミナー目次 :
=============

12:00-12:50

1. HCI が定番になりつつある背景
2. vSAN 技術概要
3. やっぱり vSAN がベストな理由
4. HCI 導入にあたる不安要素を取り除こう!
5. まとめ

12:50-13:00

QA

 

【リアルタイム実況!!】1 時間で vSAN 初期構築はどこまでできる!?

vSphere / vSAN オンラインセミナー 2019#3

 

対象 : パートナー企業様、エンドユーザー様
※競合企業、もしくは対象外と判断させていただいた方は、ご遠慮いただく場合がございます。

主催 : ヴイエムウェア株式会社

日時: 2019年 04 月 24 日(水) 12:00-13:00 (11:50 から受付開始)

費用: 無償

申し込み : こちらよりお申込みください。

講演者 : ヴイエムウェア株式会社 内野 賢二

■ セミナー目次 :
=============

12:00-12:50

1. 検証環境への接続/vCenter への接続
2. 検証環境の確認 / VMware vSAN の有効化
3. ノードの追加・ディスクの追加作業
4. 仮想マシンストレージポリシーの設定作業
5. 仮想マシンの作成およびディスクレイアウトの確認

12:50-13:00

QA

 

では、当日のオンラインセミナーでお会いできることを楽しみにしております。

また、今後、定期的にオンラインセミナーを行う事を計画しております。

今後、取り扱って欲しい内容等がございましたら、是非、オンラインセミナーご参加時に直接、コメントを頂ければ幸いです。

VMware 内野

The post Microsoft SQL や Exchange サーバーを VMware vSAN で稼働させるリファレンスアーキテクチャのご紹介・vSphere / vSAN オンラインセミナー実施のお知らせ(2019年04月) appeared first on Japan Cloud Infrastructure Blog.

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

$
0
0

Part2: VCFのメリット

ー Back Number ー

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

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

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

#4   VCFはHPE Synergy との連携に優れている

 

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

 

連載第2回は、VCF(VMware Cloud Foundation)はどのようなお客様向けの製品なのかをご説明します。

 

今回お伝えしたことは、大きく3つです!

 

  1. VMware開発者の理想形が手に入る
  2. SIerさんも嬉しい
  3. 運用中も理想形のまま維持される

 

◆ 1. VMware開発者の理想形が手に入る ◆

 

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

共通技術で稼動するシステムがプライベートクラウド上とパブリッククラウド上にあれば、もうおわかりですよね。

――――そうです。

それぞれがシームレスに連携可能になります。わかりやすい例を1つ挙げると、VCF環境にインターネット接続が整っていれば、プライベートクラウドとパブリッククラウドの仮想マシンが相互vMotionすることが可能になります。

では、もしVCFを導入していないVMware仮想化環境でプライベートクラウドとパブリッククラウドをシームレスに連携させるとどうなるでしょうか??

 

下記のようなコンポーネントを一から ”1つ1つ” 構築をしていくことになります。

これらを構築するとなると、様々なソフトウェアを設計し、セットアップし、設定項目も判断しなければなりません。各々は連動もするでしょうから、相互の動作テストも必要です。何十時間、場合によっては何百時間も必要な設計と構築作業―――。うんざりしてしまいますよね。

 

第1回でもお伝えしたとおり、VCFには専用のセットアップツールが付属します。

これで構築を行うとどうなるのでしょう??

 

なんと、 開発元が想定した“理想形”が復元される んです!!

 

先ほどのソフトウェア(コンポーネント)は担当者の設計・判断は必要なく、開発元であるVMware社の最も理想とする形にセットアップされます。せっかく予算化して調達したのですから、良いもの・理想的なもの・高品質なものを手に入れたいのは担当者にとって当たり前のこと。開発元の想定した“理想形”であれば不安もないですし、安心です。

◆ 2. SIer さんも嬉しい ◆

日本のIT現場では“SIerさん”も無くてはならない存在です。

ツールを用いたセットアップはお客様だけはなく、SIer様にもメリットがあります。

 

1つは誰でも構築できること。担当者は実行ボタンをクリックはしますが、実際にセットアップするのはツールの中にいる“ロボット”です。ヒトに判断を委ねることもほとんどありませんので、引っ張りだこの“スーパーエンジニア”でなくとも品質を一律に保ってセットアップできます。そして早い

VCFのセットアップツールは高品質なうえに驚異的な早さでセットアップしてくれます。私が検証したときはナント セットアップ時間 1時間54分 で完了しました。

自動セットアップ完了時の画面 「Bringing Up the SDDC」

vSANやNSX・vRealizeといったVMware SDDCインフラを構築したことがある方であればこれが驚異的な早さであることはお分かりいただけるはず。忙しい設計担当者(アーキテクト)の工数も大きく削減可能です。

◆ 3. 運用中も理想形のまま維持される ◆

では、設計・構築の話はここまでにして、ここからはお客様が最も気になる「運用フェーズ」の話をしたいと思います。

いきなりですが、従来のVMware環境と、理想的な形でセットアップされたVCF環境は運用にどれくらいの違いがあるか説明していきます。

 

◇従来のVMware環境◇

運用を開始し、半年、1年、2年と経過していくと、メインコンポーネントであるVMware vSphere(ESXi)やNSX、管理コンポーネントであるvCenter Server・vRealizeといった各ソフトウェアに新しいバージョンが次々とリリースされていきます。機能強化だけではなく、脆弱性に関するパッチも含まれるため、セキュリティ対策のためにも定期的なアップデートが求められます。

 

これとは逆に“バージョン塩漬け”を好まれるお客様もいらっしゃいますが、VMware製品には製品ごとにサポート期間が設けられており、「サポート切れ」予告が次々に襲ってきます。このようなシステムでは計画停止もタイミングもなかなかありませんし、後手後手でバージョンアップしていくと、各コンポーネント間の互換性チェックが疎かになったり、知らぬ間に相互連携機能が正しく動かなくなってしまう―――。

 

その結果どうなるでしょうか??

 

導入当初どれだけ完璧な状態に構築されても、実際に運用が始まり、日が経つにつれてメーカーの理想形からどんどんかけ離れていきます。

気がついたら、サポートされない組み合わせになっていた・・・なんてことも良く聞く話です。

 

参考:「VMware Product Interoperability Matrices」
https://www.vmware.com/resources/compatibility/sim/interop_matrix.php

 

 

◇VCF環境◇

では、VCFを導入している環境ではどうでしょうか。

もちろん、従来環境と同様に、VCF環境でも半年、1年、2年が経過していくと、コンポーネントごとに次々と新しいバージョンがリリースされていきます。

 

しかし!

VCF環境にはバージョン管理の“救世主”として「VMware SDDC Manager」がいます。

 

覚えていますか?? Part1 でご紹介した「導入」「構成」「プロビジョニング」「パッチの適用」といった一連のライフサイクル管理を自動化して運用を大幅にラクにするツールです。

 

VCF環境はメーカーの理想形で完璧に構築されるだけでなく、お客様の運用が始まっても、SDDC Managerが理想の状態を維持してくれます。各コンポーネントにパッチがリリースされたりバージョンアップしても、「互換性を考えながら」「最適な手順で」「管理者の手を煩わせずに」最新の状態にアップデートしてくれます。従来と一線を画すこの管理手法は「自動ライフサイクル管理」と呼ばれています。

 

 

 

自動ライフサイクル管理により、理想の状態が保たれますので、運用管理者は不安なく、いつも安心して日々の運用を続けていくことができるというわけです。

 

これまでのようにバージョンアップを検討するたびに「これとこれの組み合わせは大丈夫だったかな・・・」と毎回考えないでよいと思うと、大きな重荷から解放されますよね!!

 

 

今回は、VCFを導入することにより、お客様のメリットをご紹介しました。

 

VCFはVMware開発者の理想形で構築され、それを維持し続けることができる。みんな幸せ!

 

この一言を是非、記憶に留めていただければと思います。

次回は今回取り上げたセットアップツールを解説していきます、是非ご期待ください!

 

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

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

前職ではプログラマー、HPEでは仮想化のサポートエンジニアを経験後、プリセールス部門に転身。技術が好きでVMware製品やMicrosoft製品の提案や、ProLiantサーバーを中心としたハイブリッドクラウドの提案などに従事。

 

The post VMware Cloud Foundation でハイブリッドクラウドへ踏み出そう appeared first on Japan Cloud Infrastructure Blog.

タイムマシンをお持ちでない方向け仮想化基盤移行の話

$
0
0

皆様、はじめまして。  日本ヒューレット・パッカード(HPE)でサーバーの仕事をしています齋藤豪(さいとうごう)と申します。

突然ですが、皆様の環境には仮想化基盤はありますでしょうか。そのシステムは何年前に入れたものですか?と言うのも、古いものだとそろそろバージョンアップを考えないと不要なリスクを負うことになってしまうんですよ。

 

環境を塩漬けにしていませんか? vSphere 5.5のEOGS(End Of General Support)

例えばお使いの環境がVMware vSphere 5.5の場合、General Supportが終了し、既にセキュリティリスクが発生していると言うことができます(General Supportが終了しているため、既にセキュリティを含むパッチは提供されません)。

でも、自分は大丈夫だと思っていませんか?近年、感染すると恐ろしい被害をもたらすマルウェアの1つが流行していますが、JPCERT/CCの調査 (2018/7/30発表)によると、調査した組織のうち、35%がLockyやWannCryなどのランサムウエアの被害を経験したと発表されています。

タイムマシンをお持ちでない限り時間は遡れません。既に今日現在はGeneral Supportが終了した“黄信号”の状況ですので、お早目の更改をご検討ください。(もしお持ちの方がいたら詳しくお話聞かせください)また、vSphere 6.0 についても2020年3月にGeneral Supportが終了し、“黄信号”に入ります。なので、寿命の長い最新のvSphere 6.7へのアップデートが激しくオススメなのですが、古いサーバーだと最新のvSphereバージョンがサポートされていない場合もあります。

 

環境を塩漬けにしていませんか?(Gen8サーバの保守期限が近付いています)

今ご利用のサーバはどの世代でしょうか?

ご購入時期が2012年9月~2015年頃の場合、HPEで言うとGen8世代のサーバー(Intel Xeon E5-2600v1、v2を搭載のもの)に該当するかと思います。販売終了から5年を迎え、一般的に機器の老朽化による故障も心配ですし、保守契約が終了してしまった機器の場合はパーツ交換ができないことも考えられます。

また保守が受けられないということは、サーバに同梱されているファームウエアの改良版の提供も受けられないということになります。2018年最初には、大規模セキュリティインシデントとなった「Meltdown」 と 「Spectre」という、近年発売されたほとんどのプロセッサにおいて深刻なセキュリティホールが存在するというニュースが流れましたが覚えておられるでしょうか?ほぼすべてのデスクトップOSとモバイルOSの搭載端末に影響を与える大問題で、対策にはファームウエアのアップデートが必要になります。このような場合でも、保守切れのサーバには対策されたファームウエアがリリースされません。

安心して日々の業務を行って頂くために、またご自身のお客様のために、vSphere 6.7へのアップグレードと共に、新しいサーバーへの移行もご検討ください。

 

HPEのサーバーなら結構安心

リプレース先としては、HPEのサーバーがすごくオススメです。

リプレース先としては、HPEのサーバーがすごくオススメです。(2回目)

x86サーバーはご多分に漏れず、最新モデルの性能は結構あがっていますので、そもそもの集約効率や費用対効果の向上が見込めます。

それだけではなく、HPEサーバーならではの充実したセキュリティ機能があります。

サイバーセキュリティに関する怖いニュースが後を絶ちません。攻撃者の狙い目がネットワークからサーバーにも及び始めていることから、HPEの最新サーバーは全てファームウェアレベルでの改ざん検知・復旧機能を持っています。しかも標準搭載。無償です。

 

vSphere 6.7への移行と、どうせならもう少し楽でイケてるインフラを

肝心な移行方法につきましては、お客様環境にもよるので一概には言えませんが、HPEでも移行のお手伝いをさせて頂くことが可能です。こちらについては、後述のウェビナーでもご紹介予定です。

ここで、仮想化基盤の更改と合わせてご検討頂きたいインフラ技術についても少しご紹介します。

ストレージ専用装置はもちろん優秀ですが、コストや求められるスキルの専門性から負担になっているケースも多く見受けられます。そこで普及が進んでいるのがSDS(ソフトウェアデファインドストレージ)を用いたHCI(ハイパーコンバージドインフラ)です。めっちゃ横文字。。要はサーバーの内蔵ディスクを共有ストレージとして使う技術がかなり充実してきたというお話で、VMware vSANであればいつも仮想化環境でお使いの管理画面からストレージの管理も行えます。

そしてもちろん、HPEサーバーはお客様のシステム規模やご要件に応じて最適なものをご提案させて頂きます。コスト重視環境ならばAMD EPYC プロセッサ搭載のProLiant DL325、小~中規模環境ならProLiant DL380、サーバー数が4台以上になるような基盤や外部ストレージとの併用、仮想化しきれない環境も混在する場合はHPE Synergyがおすすめです。

単に従来型のサーバー・ネットワーク・ストレージ構成(3-Tier)をHCI 化するだけでなく、ネットワーク仮想化であるVMware NSX Data Centerや、運用監視のためのVMware vRealize製品群も取り入れたSDDC (Software-Defined Datacenter)をご希望であれば「VMware Cloud Foundation (VCF)」を検討することをお勧めします。VCFであれば、VMware Cloud on AWS に代表されるようなVMwareベースのクラウドとのハイブリッドクラウドも実現可能です。詳しくは弊社の片山の投稿を是非ご覧ください。

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

 

ウェビナーのご案内

少々長くなりましたが、VMwareさんとHPEで共同開催するウェビナーでより詳しく解説します。

vSphere 5.5のジェネラルサポート終

今だから知りたいVMware最新情報と移行の勘

日時: 2019年06月 04日 (火)11:00 -11:45

以下のリンクよりお申込みください!

https://event.on24.com/wcc/r/1991399/6CB64B78C708EF56A0C80F5AB5C14847?partnerref=VMBlog

齋藤豪(さいとう ごう)

日本ヒューレット・パッカードのプリセールス部門に所属。HPE入社以来金融業界のお客様を担当し、現在はコンポーザブルインフラ、ハイパーコンバージドインフラの提案、ビジネス開発活動に従事。好きな音楽はMYTH&ROID。

The post タイムマシンをお持ちでない方向け仮想化基盤移行の話 appeared first on Japan Cloud Infrastructure Blog.


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

$
0
0

Part3: 理想のSDDC環境をツールで一気にセットアップ!

ー Back Number ー

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

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

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

#4   VCFはHPE Synergy との連携に優れている

 

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

 

連載第3回は、VCF(VMware Cloud Foundation)のセットアップ方法についてご紹介いたします。

 

前回の連載では、VCFは VMware社の理想形で構築され、さらに構築が早い!”ことをお伝えしました。では、 VCFのセットアップは実際に「どのような流れで進めていくのか」「本当に構築が早いのか??」、またSDDC(Software-Defined Datacenter)インフラを構築するにあたり、“VCFアリ”と “VCFナシ”では、どれくらい作業内容に差があるか見ていきましょう。

 

◆スクラッチでのセットアップと、専用ツールでのセットアップ◆

◇スクラッチで1個1個セットアップ◇

ホストごとに設定画面を開き、細かい部分まで手作業で設定していくという大事ではあるけれど、時間がかかって辛い仕事―――。

これらの作業を手動で実施すると1週間以上かかっていたなんてこともありますよね?

また、集中力が切れてしまい「途中1台だけミスをしまう」ことや、そのミスに気づかずに1台だけ設定が異なってしまうことで、隠れた癌のように後々カットオーバー後に性能や安定性に影響を及ぼしてしまうリスクもあります。

◇専用ツール◇

では、VCFだとどうでしょう?

VCFには専用のセットアップツールが付属しています。用意されたパラメーターシートにホスト名、IPアドレス、ライセンスキーなどを入力し、セットアップVM(Cloud Builder VMといいます)にブラウザからアップロードするだけで、各種SDDCコンポーネント(ESXivCenterNSXvSANvRealize:オプション)がVMware社の理想とする“完璧な状態”で出来上がります!

作業時間はもとより、「設計ミス」「構築ミス」から解放されます!

◇パラメーターシートの入手◇

VCFのセットアップはパラメーターシートの入手から始まります。私は前職SIerで勤務していたのでよくわかりますが、パラメーターシートというと会社ごとに書式が決まっていたり、パッと見て分かりづらいものも多かったりするのが実情ですよね。

しかし、VMware社が専用のパラメーターシートを用意してくれています!!

こういったところもVMware社は利用者(構築者)目線だと思いませんか。

 

入手方法ですが、MyVMwareにログインをして「Cloud Builder Deployment Guide」(Excel形式)をダウンロードすることができます(※)。

ファイル名:vcf-ems-deployment-parameter_VCF3.X.X.xlsx

※本稿執筆時の最新バージョンである「バージョン3.7.1」の場合、次のURLからアクセス可能です。

https://my.vmware.com/jp/group/vmware/details?downloadGroup=VCF371&productId=865

 

◇パラメーターシートの記入◇

Excelでパラメーターシートを開くと、視覚的にわかりやすいレイアウトになっていることが分かります。タブがいくつか用意されていますが、サンプルとして既にIPアドレスが入力されていますので、お客様環境に合わせた内容に調整するだけです。

 

 

◇パラメーターシートをセットアップVMにアップロード◇

 

ブラウザ(Chormeなど)から https://<CloudBuilderVM IP >:8008/  へアクセスします(注)。

「UPLOAD」ボタンをクリックし、作成したパラメーターシートをアップロードしてください。

 

(注)アクセスするアドレスはバージョンにより変わります。該当するバージョンのドキュメントをご確認ください。

◇セットアップ前の不安も払拭!自動構成チェック◇

 

実機でセットアップする際は、私自身もここで不安になりました。

それは「自分が記入したパラメーターシートに内容に誤りがないか」です。入念にチェックをしても、どうしても心配になるかと思います。

しかし、安心してください!

パラメーターシートをアップロードすると、内容に矛盾がないか、誤りがないかを確認してくれます。作業者の不安まで払拭してくれるため心強いですね。

 

 

Configuration File Validation

      ※ESXi、vCenter、NSX、vSAN、vRealize 1つ1つのパラメーターチェック

 

もちろん、問題があればきちんとエラーを表示してくれます。

また、パラメーターシートに記入した「値」のチェックだけではありません。ネットワークの疎通チェックや、ESXiハイパーバイザーが正しくセットアップしているかもチェックしてくれます。

 

※次の例では意図的にESXi側でSSH接続を無効にし、SSH接続できない状態にしてエラーを表示させました。

 

◇自動セットアップの開始(Bringing Up)◇

各SDDCコンポ―ネントのセットアップ作業は「Bringing Up」と呼ばれます。視覚的に現在進行中の作業がわかる画面デザインになっています。

◇自動セットアップの完了!◇

 

約2時間待つだけ で全てのセットアップが完了します。

無事セットアップに成功すると、緑色の枠内に待ちに待った “VMware SDDC Manager”のアクセスURLが表示されます。

 

さっそくアクセスしてみましょう!

次のスクリーンショットはVMware SDDC Managerのログイン直後の画面です。

 

◇これがVMware社理想の状態!!◇

 

「VMware社の理想」と繰り返しお伝えしましたので、それがどのような状態か気になっている方も多いかと思います。みなさまお馴染みのvCenter Server(vSphere Client)の画面も用意してみました。さすがにフルスタックというだけあって、たくさんの管理系の仮想マシンが並んでいます。リソースプールも使われていますね。

vSAN の構成ももちろんバッチリです!

ここまでで、基本的なVCFのセットアップ作業は完了です。VMware理想の設計でインフラが組まれました。

 

ESXi、vCenter、NSX、vSAN、vRealizeと、それぞれ技術書籍一冊ずつ書けてしまうものが、そのセットアップをたった1回のブログ記事で書けてしまいました。。。

この点においても、VCFのスゴさを私自身が再認識してしまったところです。

 

次回は、ここまでオンプレミス環境を中心に書いてきたVCF、クラウド適用についてご紹介します。是非ご期待ください!

 

 

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

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

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

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

 

The post VMware Cloud Foundation でハイブリッドクラウドへ踏み出そう appeared first on Japan Cloud Infrastructure Blog.

第3回 シュナイダー (APC) UPS と VMware vSAN はシャットダウン連携ができるんです!! ~2 Node vSAN 対応とよくある QA編~

$
0
0

第3回 シュナイダー (APC) UPS と VMware vSAN はシャットダウン連携ができるんです!! ~2 Node vSAN 対応とよくある QA編~

 

#第1回 シュナイダー ( APC ) UPS と VMware vSAN はシャットダウン連携ができるんです!!
~導入構成編~

 

#第2回 シュナイダー ( APC ) UPS と VMware vSAN はシャットダウン連携ができるんです!!
~電力消費量計算編~

 

#第3回 シュナイダー ( APC ) UPS と VMware vSAN はシャットダウン連携ができるんです!!
~2 Node vSAN 対応とよくある QA編~

 

 

◆はじめに

 

いつもシュナイダーUPS & vSAN 連携ブログを閲覧いただきありがとうございます。

シュナイダー エレクトリック 出口と冨田です。

前回のブログでは 広島の田中電機工業社 村上さんと中野さんに自社導入実績をもとに、機器構成と消費電力量の計算方法をご紹介いただきました。

今回のブログでは多くの方からご相談を頂いていた 「2 Node vSAN での対応状況」と「サポートされる構成」、「2 Node vSAN でよくあるQA」を紹介していきます。

 

 

1.そもそも 2 Node vSAN とは?

通常の vSAN は 3台以上の vSAN ノードを用意して vSAN クラスタを構成しますが、2 Node vSANは 2台の vSAN ノードと1台の管理用ノードで実現できる最小構成の HCI です。

管理用ノードには  Witness Appliance という vSAN ノードのマスターを判定する機能を持った仮想アプライアンスと vCenter Server をデプロイします。

構成イメージは下記の図を参照ください。

 

2.2 Node vSAN でサポートされる構成

2019年6月5日 現在、 PowerChute Network Shutdown (以下略 PCNS)は バージョン4.3になり、2 Node vSAN にも対応しています。

今回紹介する構成はよくある2パターンの構成で、1つ目は2 Node vSAN システム外部の 物理Windows サーバーにPCNSをインストールするパターン。

2つ目は2 Node vSAN システム内部の Witness アプライアンスを実装した管理ノードに仮想アプライアンスとして提供されている PCNS 仮想アプライアンスをデプロイするパターンをご紹介します。

 

◆2 Node vSAN の構成におけるポイント

PCNSを外部の物理Windowsサーバーにインストールして管理する方法とESXiホストに仮想アプライアンスとしてデプロイして管理する方法がありますが、仮想アプライアンスの場合はvSANクラスタ外の管理ノードにデプロイします。
いずれの構成もUPSが電源障害を検知すると、PCNSはvSANクラスタと管理ノードのすべてのESXiホストを安全にシャットダウンします。

※こちらで紹介する構成は UPS がシングル構成、冗長構成どちらでもサポート対象となります。

 

パターン1. 外部 の物理 Windows サーバーに PCNS をインストールする構成

 

パターン2. vSAN 管理用ノードに 仮想アプライアンス版 PCNS をデプロイ

※パターン2の構成で、電源復旧後にvSANシステムを自動起動する場合には、管理ノード上にデプロイした PCNS と Witness Appliance を ESXi の機能を用いて自動起動するように設定してください。(設定方法については下記リンクを参照)

https://docs.vmware.com/jp/VMware-vSphere/6.7/com.vmware.vsphere.vm_admin.doc/GUID-5FE08AC7-4486-438E-AF88-80D6C7928810.html

 

これで2 Node でも 3 Node以上でも、安心して vSAN を導入できますね (^^♪

 

3.2 Node vSAN 構成の Tips 集

◆vSAN 用ネットワークの構成について

vSAN ネットワーク用の NIC は 10G ネットワークで構成してください。

2 Node vSAN に限り、10G NIC 直結でも、スイッチ経由でも構成可能です。

 

◆ネットワークの組み方について

vSAN のよくある質問でネットワークの組み方について聞かれることが多いと思います。

このネットワーク部分で、世界で70名ほどしかいない vExpert-vSAN の一人である「Captain大塚」こと SB C&S 大塚正之さんのBlogに良い記事がありましたので引用させていただきました。

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

大塚さん ありがとうございます m(_ _)m
https://twitter.com/masotsuka

 

・LAN内で Witness アプライアンスに2つのIPアドレスを設定しないで構成する場合

 

・ROBO構成などのように、Witness アプライアンスに2つのIPアドレスを設定して構成する場合

 

4.参考リンク

PCNS v4.2 の2 Node vSAN 対応について

https://www.se.com/jp/ja/faqs/FA350086

 

以上で3回続けてきたシュナイダーUPS & VMware vSAN ブログも今回で最後となります。

 

これからも皆様の HCI 環境を快適に動かすための情報があれば情報展開していきますのでこれからも シュナイダー社とVMware社に乞うご期待ください!!

 

The post 第3回 シュナイダー (APC) UPS と VMware vSAN はシャットダウン連携ができるんです!! ~2 Node vSAN 対応とよくある QA編~ appeared first on Japan Cloud Infrastructure Blog.

StorageHub リファレンスアーキテクチャのご紹介・vSphere/vSAN オンラインセミナー実施のお知らせ (2019年07月)

$
0
0

VMware パートナーチームの内野です。

皆様が新しいシステムを構築・提案される際に実際に上に乗るアプリケーションでどの程度、パフォーマンスが出るのかある程度、事前に把握する必要があると思います。

その際に、もちろん、物理的な機器を準備して、実際にアプリケーションをインストールおよび検証の上、パフォーマンスを確認する。という事も非常に重要なことだと思っていますが、出来れば、検証する前に検証するための推奨構成 (リファレンスアーキテクチャ) を事前に確認できたら。と思う方は多いのではないでしょうか。

VMware では、下記の Storage Hub リファレンスアーキテクチャーというページで各アプリケーションメーカー様や用途、業界向けの推奨構成一覧をまとめているページをご用意させて頂いております。

https://storagehub.vmware.com/t/vmware-vsan/reference-architecture/

この中で “Oracle and MySQL” をアプリケーションとして載せる場合の vSphere & vSAN の構成例やリファレンスアーキテクチャ、”Microsoft 社” の SQL Server や MS-Exchange を構築する場合の vSphere & vSAN としての構成例やパフォーマンス結果等を事前に確認することが可能です。

 

 

今回は、全ての情報をご紹介することはできませんが、例えば、データベースと言っても数多くのデータベース製品がございます。StorageHub の中の情報では、Oracle 社の Oracle データベース (12c) 、My SQL データベース、Microsoft 社の SQL Server や Mongo データベースのパフォーマンス情報等が様々な形で掲載されておりますので、色々なシチュエーションに応じた情報をご準備させて頂いております。

 

 

Oracle データベースのパフォーマンスデータの例

 

 

My SQL データベースのパフォーマンスデータの例

 

 

SQL Server データベースのパフォーマンスデータの例

 

 

Mongo データベースのパフォーマンスデータの例

 

 

パフォーマンスデータはハードウェア構成やソフトウェア構成、テスト方法等も正しく確認しないと想定しているシステムの要求と異なる結果になってしまう事もあると思いますが、Storage Hub では、ハードウェア構成やソフトウェア構成(バージョン等)、テストツール等の実行方法の記載もございますので、是非、参考にして頂ければ幸いです。

なお、上記でもご紹介している VMware vSAN に関して、2019 年 7 月にオンラインセミナーを実施させて頂くこととなりました。

(注意 : 上記、アプリケーションのリファレンスアーキテクチャ等の詳細に関する内容はオンラインセミナーでは含まれておりませんのでご注意下さい)

今回は、下記の 3 つのオンラインセミナーを実施させて頂きます。

 

外部ストレージはもう古い!! 3階層から VMware vSAN HCI への移行がもたらす効果

vSphere / vSAN オンラインセミナー 2019#4

最近では、これまでハイエンドストレージで稼働していた重要な業務が VMware vSAN をベースとした HCI に移行されている事例がいくつもあり、移行されたお客様は HCI のメリットをご体感いただいています。どんなお客様が、どのような課題を従来環境に抱えていて、それを VMware vSAN HCI がどのように解決したのか? “にわかに信じがたい、嘘のような本当の話” を実例を用いてお伝えします。

対象 : パートナー企業様、エンドユーザー様
※競合企業、もしくは対象外と判断させていただいた方は、ご遠慮いただく場合がございます。

主催 : ヴイエムウェア株式会社

日時: 2019年 07 月 12 日(金) 12:00-13:00 (11:50 から受付開始)

費用: 無償

申し込み : こちらよりお申込みください。

講演者 : ヴイエムウェア株式会社

■ セミナー目次 :
=============

12:00-12:50

1. VMware vSAN 概要紹介
2. 3階層構成の課題
3. VMware vSAN 導入までの検討事項
4. VMware vSAN 導入効果

12:50-13:00

QA

 

Hyper-V 環境からの vSphere 環境への移行手法ご紹介

vSphere / vSAN オンラインセミナー 2019#5

Windows Server 2008 R2 の延長サポート期間が 2020 年 01 月 14 日と迫ってきております。次期仮想基盤として vSphere/vSAN を用いた最新 HCI 環境をご検討頂いている方向けに Hyper-V から vSphere 基盤への移行方法に関してご紹介します。

対象 : パートナー企業様、エンドユーザー様
※競合企業、もしくは対象外と判断させていただいた方は、ご遠慮いただく場合がございます。

主催 : ヴイエムウェア株式会社

日時: 2019年 07 月 17 日(水) 12:00-13:00 (11:50 から受付開始)

費用: 無償

申し込み : こちらよりお申込みください。

講演者 : ヴイエムウェア株式会社

■ セミナー目次 :
=============

12:00-12:50

1. HCI 最新情報ご紹介
2. VMware vSAN 概要紹介
3. Hyper-V 環境からの移行方法に関して

12:50-13:00

QA

 

 

 

HCI 導入シェア No1 : VMware vSAN 導入事例紹介

vSphere / vSAN オンラインセミナー 2019#6

基盤更改を迎える多くのお客様にとっても、 “HCI” が選択肢に入っているのではないでしょうか。
本セミナーでは、次の基盤をご検討中の皆様に向けて、”VMware vSAN HCI” の実際の導入事例を用いて、

・どんなお客様が導入しているのか?
・どんな課題をお持ちのお客様だったのか?
・導入後にどんなメリットを得ているのか?

を解説します。

“百聞は一見にしかず” 皆様と同じ課題をお持ちのお客様が “VMware vSAN HCI” で課題を解決している実例をぜひ見つけてみてください!

対象 : パートナー企業様、エンドユーザー様
※競合企業、もしくは対象外と判断させていただいた方は、ご遠慮いただく場合がございます。

主催 : ヴイエムウェア株式会社

日時: 2019年 07 月 26 日(金) 12:00-13:00 (11:50 から受付開始)

費用: 無償

申し込み : こちらよりお申込みください。

講演者 : ヴイエムウェア株式会社

■ セミナー目次 :
=============

12:00-12:50

1. HCI 最新シェア情報のご紹介
2. VMware vSAN 概要紹介
3. 海外 VMware vSAN 事例紹介
4. 国内 VMware vSAN 事例紹介

12:50-13:00

QA

では、当日のオンラインセミナーでお会いできることを楽しみにしております。

また、今後、定期的にオンラインセミナーを行う事を計画しております。

今後、取り扱って欲しい内容等がございましたら、是非、オンラインセミナーご参加時に直接、コメントを頂ければ幸いです。

VMware 内野

The post StorageHub リファレンスアーキテクチャのご紹介・vSphere/vSAN オンラインセミナー実施のお知らせ (2019年07月) appeared first on Japan Cloud Infrastructure Blog.

ハイブリッドクラウドをより身近な存在に!

$
0
0

 

 

 

ハイブリッドクラウドの新しい選択肢!

~Dell Technologies Cloud~

こんにちは。Dell EMC でクラウドソリューションを担当している吉田尚壮です。今回から 4 回に渡り、この場をお借りして Dell EMC のクラウドソリューションと具体的な製品について、弊社の各専門家よりご紹介します。

 

ハイブリッドクラウドを促進するインフラ製品を強化!

 

これまで Dell EMC は VMware 製品とのインテグレーションを積極的に進めてきました。さらに今後は VMware が掲げるクラウドのビジョンにアラインする形でハイブリッドクラウド化を支援する製品やサービスを強化しました。

 

 

 

 

 

 

 

 

 

図 1 : Dell EMC はエッジとプライベートクラウドに注力

 

その最初の取り組みとして、VMware Cloud Foundation(以下 VCF)とのインテグレーションを強化したインフラ製品を増やしました。今後も新しいサービスを提供する予定がありますが、まずはその主役である VCF について簡単におさらいしておきましょう。

 

これまでの導入や運用手法をガラッと変える新基準プラットフォーム!

VCF は、従来のインフラ導入や運用手法を一変させるような新しい価値を提供する SDDC プラットフォームです。VCF を採用すれば、SDDC 環境の構築作業を簡素化し、作業時間も大幅に短縮できます。それを実現するコンポーネントが「SDDC Manager」です(図 2)。

 

 

 

 

 

 

 

図 2 : VMware Cloud Foundation の主要コンポーネント

 

SDDC Manager は、VCF の主要コンポーネントの一つで、VMware の各種ソフトウエアのインストールと構成を管理者に代わって自動的に処理してくれます。例えば、新しく SDDC 環境を構築するシーンを考えてみましょう。これまでは、マニュアルで vCentervSpherevSANNSX をそれぞれインストールしてから設定するという作業が必要でした。しかし、SDDC Manager を利用すれば、簡単な操作で完了します。SDDC Manager のダッシュボード(図3)から使用可能なホストを選択したのち、ウィザードに従って必要なパラメータを入力し、実行ボタンをクリックするだけです。あとは自動的にインストールと設定を処理してくれます。

 

 

 

 

 

 

 

 

 

図 3 : リソースの使用状況と構成が把握できる「SDDC Manager」のダッシュボード画面サンプル

 

同様に、vRealize OperationsvRealize Automation などのインストール作業も SDDC Manager から実行できます(図4)。インストールの処理が自動化されることは、管理者にとって時間の節約だけではなく、作業が失敗するリスクを低減させるメリットもあります!

 

 

 

 

 

 

 

 

図 4 : SDDC Manager から vRealize Suite 関連ソフトウェアを展開する際の画面サンプル

 

これで塩漬けから脱却!SDDC環境を常に健康な状態で維持できる!

 

もう一つ、VCF を採用するメリットがあります。最近、ソフトウェアの定期的なアップデートは必須だと言われるようになりました。ソフトウエア機能の拡張や新機能追加の頻度が多いことが一因と言えますが、最大の理由はセキュリティの担保です。攻撃手法が巧妙化しているサイバー攻撃からシステムを守るために、管理者はソフトウェアの脆弱性に対して迅速に処置する必要に迫られています。

 

しかし、ソフトウェアのアップデートとパッチ適用作業は多くの管理者にとって大きな悩みでした。製品ごとに互換性と作業手順をチェックしなければならず、マニュアル操作による面倒なアップデート作業が必要だからです。また、安全に作業を遂行するためには事前にテストする必要があるなど、容易に準備を進めることができないため、不本意ながら結局塩漬けにするケースが多かったと思います。

 

ご安心ください。VCF ならこの悩みが一気に解決します!VCF には VMware 製品のライフサイクル管理機能が標準搭載されているので、簡単な操作でアップデート作業を完了できます!

 

 

 

 

 

 

 

図 5 :  SDDC Managerのダッシュボード(アップデート処理の確認)画面サンプル

 

操作はとても簡単です。SDDC Manager のダッシュボードからアップデート対象の環境を選択し、アップデートの内容を確認します(図5)。その後、環境の健全性をチェックしてから、問題なければそのままアップデートを実行します。処理は自動化かつオンラインで実行されるので管理者の負担が軽減されますし、当然作業が失敗するリスクも回避できます。ちなみに、アップデート処理はスケジュールを設定しておいて、任意のタイミングで実行させることもできます。

 

VCFの価値を最大化するのがハイパーコンバージドインフラ!

 

このように理想的な SDDC 環境を提供してくれる VCF ですが、どんなハードウエア製品と組み合わせるのが良いのでしょう?その答えは「ハイパーコンバージドインフラストラクチャ (以下HCI)」です!Dell EMC の HCI 製品である「VxRail」は、予め vSphere がバンドルされた状態でデータセンターに搬入されます。それをラッキングして電源投入した後、数十分で vSphere と vSAN を構成し、vCenter にアクセスできるようになります。納品直後から使えるので、構築作業に対する管理者の工数は殆ど考慮する必要はありません。さらに、VxRail はハードウエア層およびバンドルされているソフトウエア(vSphere や vSAN など)を対象としたライフサイクル管理機能が標準装備されています。つまり、物理ホストから vSphere までのアップデート作業は VCF と同じように自動的に処理できるのです(図6)!

 

 

 

 

 

 

 

図 6 :  究極の SDDC プラットフォーム「VCF on VxRail」

 

この HCI 製品「VxRail」と VCF を組み合わせば、ハードウエア層を含めた SDDC 環境のライフサイクル管理が理想的な形で維持できます。まさに、最強の組み合わせと言えるでしょう!Dell EMC は、VCF と VxRail を組み合わせて「VCF on VxRail」として販売しています。この詳細は次の投稿で詳しくご紹介します。

 

大容量ストレージなど、あらゆるニーズにも対応!

 

IT の多くのワークロードは、HCI と VCF の組み合わせで構成される SDDC 環境でカバーすることができるでしょう。しかし、お客様によっては「一度構築した環境で 3 年間は維持するのでホスト(ハードウエアリソース)の拡張性は要らない」とか「VCF は導入したいがハードウエア製品はこちらで選びたい」、または「VCF 環境で大容量ストレージも併用したい」というご要望も実際に存在します。

 

これらのご要件に対応するため、Dell EMC は VCF が使える製品ラインナップを増やしていきます(図7)。具体的には、VCF をバンドルしたコンバージドインフラ製品、およびサーバー、ストレージ、ネットワーク製品と VCF を個別に組み合わせたリファレンスアーキテクチャを提供します。例えば Dell EMC が提供するモジュラー型サーバー(PowerEdge MX シリーズ)と VCF を組み合わせれば、ソフトウェアとハードウェアの両面で統合管理を実現できます。この辺りの詳細は、本連載の後半でご紹介します。

 

 

 

 

 

 

 

図 7 :  VCF をベースとしたインフラ製品ラインナップ

 

管理者不在のエッジもカバー!

 

更に、Dell EMC はエッジまで VCF の価値を届ける取り組みも進めます!VMware が 2018 年に発表した「Project Dimension」 をご存知でしょうか?これは、SDDC を搭載したコンピュートリソースをエッジに提供するフルマネージドサービスの開発プロジェクト名です。それを世界で初めてVMware と協業してサービス化しようとしているのが Dell EMC なのです!このサービスは「VMware Cloud on Dell EMC」という名称で 2019 年の下期から北米にてリリース予定です。

 

 

 

 

 

 

 

 

 

図 8 :  SDDC をクラウド消費モデルで調達する新しいサービス「VMware Cloud on Dell EMC」

 

お客様がこのサービスを利用する流れをご紹介します。お客様は VMware が提供する本サービスのダッシュボードから必要なコンピュートリソースを選択して、それを配備する場所を指定します。次に注文ボタンをクリックすれば、数週間後に指定した場所に SDDC が配備され、使用できる状態になります。

 

尚、選択するコンピュートリソースとは、前述した VCF と VxRail に SD-WAN (VMware SD-WAN by VeloCloud) を搭載したネットワーク製品の組み合わせであり、SDDC のコンピュートリソースとして予めパッケージ化されて提供されます。

 

お客様が調達したコンピュートリソースは、管理コンソールから一元的に管理できます(図8)。尚、ハードウエアとソフトウエアのメンテナンスは、VMware と Dell EMC がサービスの一環として実施します(図9)。「VMware Cloud on Dell EMC」は、既存データセンターも対象とするサービスなので、新しいコンピュートリソースの調達方法として注目されるでしょう。

 

 

 

 

 

 

 

 

 

図 9 : 「VMware Cloud on Dell EMC」のサービス内容

 

ハイブリッドクラウドにご興味があれば、Dell EMC にご相談を!

 

Dell EMC は、ここでご紹介した製品やサービスをまとめて「Dell Technologies Cloud」とい名称で展開しています。VMware のクラウドに対するビジョンにアラインして製品やサービスに落とし込み、ハイブリッドクラウドの現実解としてお客様に提供しています。ご興味があれば是非とも Dell EMC にお声がけください!

 

 

 

 

 

 

 

図 10 :  ハイブリッドクラウドを実現するサービスと製品を包含する「Dell Technologies Cloud」

 

次回は、技術面から「VCF on VxRail」に関して詳しくご紹介します。

 

<連載リンク>

第1回 ハイブリッドクラウドの新しい選択肢!~Dell Technologies Cloud~

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

第3回 VCF on VxRailの構築と運用

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

 

The post ハイブリッドクラウドをより身近な存在に! appeared first on Japan Cloud Infrastructure Blog.

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

$
0
0

 

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

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

 

The post VMware Cloud Foundation on VxRailから始めるオンプレクラウド appeared first on Japan Cloud Infrastructure Blog.

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

$
0
0

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)

 

 

The post Deep Security 12.0リリース! VMware 関連アップデートのご紹介(1) appeared first on Japan Cloud Infrastructure Blog.

VMware Cloud Foundation on VxRail の構築と運用

$
0
0

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

The post VMware Cloud Foundation on VxRail の構築と運用 appeared first on Japan Cloud Infrastructure Blog.


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

$
0
0

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.  
     

    The post Deep Security 12.0リリース! VMware関連アップデートのご紹介(2) appeared first on Japan Cloud Infrastructure Blog.

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

$
0
0

こんにちは! 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 のご紹介~

The post 次世代アーキテクチャのモジュラー型サーバの VCF での活用 ~PowerEdge MX のご紹介~ appeared first on Japan Cloud Infrastructure Blog.

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

$
0
0

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サーバーを中心としたハイブリッドクラウドの提案などに従事。

The post VMware Cloud Foundation でハイブリッドクラウドへ踏み出そう appeared first on Japan Cloud Infrastructure Blog.

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

$
0
0

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

アステック株式会社は大阪に本社をかまえ、制御系システムソフトウェア開発を中心とした「ソフトウェア開発」部門と、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 の構成や導入に関する情報を書かせていただきました。

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

The post vSAN の新しいカタチ ~ 2 Node vSAN を複数拠点にバラ撒いて集中管理をしましょう ~ appeared first on Japan Cloud Infrastructure Blog.

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

$
0
0

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シームレスアップデートによるアップデートの簡素化

 

The post Deep Security 12.0リリース! VMware関連アップデートのご紹介(3) appeared first on Japan Cloud Infrastructure Blog.

Viewing all 861 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>