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

月別アーカイブ: 2018年7月

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

エージェントレス型セキュリティ環境におけるWindows 10 Creators Updateの対応

 

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

Windows 10環境への移行が進む中でWindows 10 Creators Updateへの対応についてご質問を頂くことが多くなってきております。
仮想デスクトップ環境では、Creators Updateがリリースされた場合にVMware vSphereVMware NSXVMware Horizon、VMware Toolsを確認する必要があります。そして、エージェントレス型セキュリティ対策ではさらにDeep Security Virtual Appliance(DSVA)との互換性を意識していく必要があります。今回は各ソリューションが互換性の面でどのような関係性があり、どのようなポイントを確認していけばよいか、順を追って解説したいと思います。

 

仮想マシンOSがVMware仮想環境で利用できるか確認するポイント

仮想マシンにはポップアップツールであるNotifierを除いてセキュリティ機能を提供するDeep Securityのコンポーネントは導入されません。DSVAによるエージェントレス型セキュリティを提供するためには、仮想マシン側にVMware Tools のVMCIドライバに含まれるNSXファイル自己検証ドライバ(vsepflt)を導入しておく必要があり、NSXファイル自己検証ドライバがフックする情報を基に不正プログラム対策などの機能を提供しています。
詳細は第5回ブログをご覧ください。

VMwareの仮想環境上でどのWindows OSが利用できるかを確認するためには、VMware Tools とOSの互換性をチェックする必要があります。
確認のポイントは以下の2つです。

1) 仮想マシンに導入するOSがVMware Toolsに対応しているかを確認する
 VMware Compatibility Guide にて確認することができます。

2) VMware Toolsが利用を予定している vSphere / NSX に対応しているかを確認する
 VMware Product Interoperability Matrices にて確認することができます。

ここでのポイントは、該当するWindows OSがサポートするVMware Toolsを確認し、VMware Toolsが利用可能なvSphereNSXの組み合わせを把握する、という点です。この組み合わせ(=互換性)が満たされていないとVMwareのサポートを受けられなくなる可能性がありますので、必ずチェックをしましょう。

 

エージェントレス型セキュリティ提供可否を確認するためのDSVA互換性チェック

導入する仮想環境のバージョンが確認できたら、その環境でDSVAが利用可能かを確認します。
DSVAの互換性は、vSphere及びNSXのバージョンに依存します。VMware Toolsとは直接の互換性を持っていません。また、仮想デスクトップ環境において利用されるHorizonとも依存関係はないので意識する必要はありません(もう少し踏み込むとvCenter Server、NSX ManagerがDeep Security Managerと連携できれば、仮想デスクトップ展開ソフトウェアは意識しない)。
以下のサイトにてDSVAがvSphere及びNSXのどのバージョンと互換性があることをDeep Securityのバージョン毎に確認することができます。

Deep Security and VMware compatibility matrix

 

DSVA利用時のWindows 10 Creators Update の対応について

ここまでの解説を見てお分かりいただけたかと思いますが、DSVA環境における利用可能なOSは直接的にはVMware Toolsのバージョンに依存します。VMware Toolsについては、仮想マシンのOS種別単位で対応が定義されており、Windows 10のCreators Update(RS3、RS4など)のサービスオプションごとの互換性を意識する必要はありません。 対応OSについては、VMware Toolsのリリースノートを参照してください。

 

[参考情報]VMware HorizonのWindows10のサポート

DSVAとの互換性とは直接関係ありませんが、Horizonによる仮想デスクトップ環境の導入の際にはOSがどのようにサポートしているかを確認する必要があり、よくご質問をいただきますので、その情報もここでご案内しておきたいと思います。

以下のKBにはHorizonのWindows 10のサポートバージョンが記載されていますが、あくまでHorizonの互換性であり、VMware Toolsの対応バージョンは考慮されていませんので上記の互換性の確認を行って対応OSの確認をする必要があります。
https://kb.vmware.com/s/article/2149393

また、Horizon環境のサポートポリシーとして、Windows10サービスオプションが「対象(Targeted)」となっているバージョンについてはTech Preview Supportということで上記KBでもサポートされないステータスとして管理されています。
Microsoftが公開しているWindowsのリリース情報も適宜確認するようにしましょう。
https://www.microsoft.com/ja-jp/itpro/windows-10/release-information

 

まとめ

仮想マシンのOSの利用できる環境を確認する方法についてご理解いただけたでしょうか?
簡単な互換性の関係をまとめると以下のようになります。

Windows 10を例にここではお話してきましたが、レガシーOS(Windows Server 2003など)の対応も同様に確認することができます。
ただし、VMware、トレンドマイクロそれぞれでレガシーサポートの対応について定義しておりますので、必ずサポートの可否、対応条件および制限事項について事前に確認するようにしましょう。

 

執筆者:
トレンドマイクロ株式会社
セキュリティエキスパート本部
パートナービジネス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. 分散ファイアウォールと連携したマルウェア検出時の自動隔離
    12. Cross-vCenter NSX 環境における Deep Security の構成ベストプラクティス

 

仮想スイッチのお作法~Network I/O Control#6~

6回目:仮想スイッチのお作法#6    (Network I/O Control#6)

– Back Number –
#1…仮想スイッチのお作法#1
#2…仮想スイッチのお作法#2
#3…vSphere 6. 5の分散スイッチの機能とアーキテクチャ#3
#4…分散スイッチの管理①#4
#5…分散スイッチの管理②#5
#6…Network I/O Control#6

日本ヒューレット・パッカード株式会社の中川明美です。

6回目は、分散スイッチが提供する「vSphere Network I/O Control バージョン3」についてご紹介します。「Network I/O Control」は、複数の種類のトラフィックが共通のリソースを使用する場合に、競合する問題を解決します。

サーバーの最新モデルによっては、10Gbpsの物理NICを16個まで搭載することができるようになりました。16個もあれば、10Gbpsの物理NICを必要なトラフィックで占有できそうですね。参考までに、vSphere 6.5の10Gbps物理NICの最大構成数は、Intel製は16個、QLogic製またはEmulex製は8個です。

数年前までは10Gbps物理NICは2個が大半で、物理NICを共有する複数の種類のトラフィックをどのようにコントロールするかは設計者の腕の見せ所だったのではないかと思います。

また、Network I/O Controlバージョン2をお使いの方で、物理NICのコントロールはNetwork I/O Controlを、仮想NICのコントロール (制限) はトラフィックシェーピングを使用されていた方もいらっしゃったのではないかと思います。

バージョン3では物理NICおよび仮想NICのリソースコントロール機能を提供しています。ぜひこの機会に、Network I/O Control バージョン3の使いどころを知っていただけたら幸いです。

 

 

◆vSphere Network I/O Control バージョン2とバージョン3

vSphere 6.0から提供されたNetwork I/O Control バージョン3では、vSphere 5.5までのバージョン2にいくつかの機能を追加しています。バージョン2と3の違いを確認します。

 

<バージョン2>

バージョン2では、たとえば仮想マシンのネットワークトラフィックで、物理NICを対象に異なるコントロールを行いたい場合、ユーザー定義のネットワークリソースプールを使用します。

新規ネットワークリソースプールで、「制限」「シェア値」「CoS優先順位タグ」を指定します。作成したネットワークリソースプールを分散ポートグループに割り当てます。

 

 

 

 

 

 

 

 

 

 

 

 

<バージョン3>

バージョン3では、仮想マシンのネットワークトラフィックで、物理NICを対象にコントロールを行いたい場合は「仮想マシンシステムトラフィック」を、仮想NICを対象にする場合は「ネットワークリソースプール」または「仮想マシンの設定」を使用します。

ネットワークリソースプールを作成する前に、仮想マシンシステムトラフィックでバンド幅の予約設定が必要です。

 

◆システムトラフィックのバンド幅割り当て

システムトラフィックには、事前に定義された9つのトラフィックタイプがあります。

物理NICを対象に、「シェア」「予約」「制限」の設定値を使用して、各システムトラフィックにバンド幅を割り当てます。バージョン3から、設定値に「予約」が追加されました。

設定値 説明
シェア 同じ物理NICを使用するシステムトラフィックタイプの優先順位の相対的な比率です。低/標準/高/カスタム (1から100) を指定します。

たとえば、FTとiSCSIに100、それ以外には50のシェア値が設定され、対象の物理NICはFT/iSCSI/vMotion用に使用されているとします。

ある時点でFTとiSCSIの2つのトラフィックが物理NICの帯域を超えたら、各トラフィックは物理アダプタのバンド幅の50%を使用します。

ある時点で3つのトラフィックが物理NICの帯域を超えたら、FTとiSCSIに物理アダプタのバンド幅の40%、vMotionに物理アダプタのバンド幅の20%が使用されます。

予約 1個の物理NIC上で確保が必要な最小バンド幅 (Mbps) です。

すべてのシステムトラフィックタイプで予約される合計バンド幅は、物理NICのバンド幅の75%を超えることはできません。

制限 1個の物理アダプタでシステムトラフィックタイプが使用できる最大バンド幅 (MbpsまたはGbit/s) です。

 

下図は、vMotionトラフィックの設定の編集画面です。この分散スイッチには1Gbpsの物理NICが割り当てられています。

 

 

 

 

 

 

 

 

 

 

<10Gbps物理NIC上のシステムトラフィックのバンド幅予約例>

たとえば、次の予約設定によって、1つの物理NICを対象に、仮想マシン用の0.5Gbpsのバンド幅を確保できたことになります。

 

◆仮想マシントラフィックのバンド幅割り当て

仮想マシンを対象に異なるコントロールを行いたい場合には、「ネットワークリソースプール」を使用する方法と、仮想マシンの設定の編集で設定する方法の2つがあります。

設定値 説明
シェア 仮想マシントラフィックをネットワークに転送する物理NICのキャパシティに応じ、この仮想マシンの仮想NICを通過するトラフィックの優先順位の相対的な比率です。低/標準/高/カスタム (1から100) を指定します。
予約 仮想マシンの仮想NICが物理NIC上で受け取る必要がある、最小バンド幅(MbpsまたはGbit/s) です。

ネットワークリソースプールは予約 (Mbps) のみの設定です。

制限 同じESXiホストまたは別のESXiホストに配置されている他の仮想マシンへのトラフィックに使用できる、仮想マシンの仮想NIC上の最大バンド幅(MbpsまたはGbit/s) です。

 

 

<ネットワークリソースプール>

ネットワークリソースプールのバンド幅割り当ては、そのプールに関連付けられている分散ポートグループ間で共有されます。仮想マシンには、その仮想マシンが接続されている分散ポートグループを介して、ネットワークリソースプールからバンド幅が割り当てられます。

デフォルトでは、分散スイッチ上の分散ポートグループは、割り当てが構成されていない「デフォルト」と呼ばれるネットワークリソースプールに割り当てられています。

 

下図を例にすると、分散ポートグループAに接続される仮想マシンに割り当てられるバンド幅の合計が最小2Gbps確保 (保証) されます。

先に述べたように、ネットワークリソースプールを使用するには、仮想マシンシステムトラフィックで予約の設定をします。

下図は、仮想マシンシステムトラフィックの設定の編集画面です。物理NICのバンド幅の75%を超えない値を設定します。

 

下図は、新規ネットワークリソースプールの画面です。ここで予約値 (最小バンド幅) を設定します。最大割り当て値は、仮想マシントラフィックで設定した予約値×アップリンク (物理NIC) の数です。このアップリンク数は分散スイッチで設定した値です。

 

 

下図は、分散ポートグループの設定の編集画面です。ここで作成したネットワークリソースプールを割り当てます。

<仮想マシン>

各仮想マシンのバンド幅割り当ては、仮想マシンの設定の編集で行います。

「制限」と「予約」は、仮想NICが接続されている分散ポートグループのトラフィックシェーピングポリシーにも依存します。たとえば、トラフィックシェーピングポリシーで平均バンド幅を100Mbpsに設定したなら、仮想マシンの仮想NICの予約値によって仮想マシンが200Mbpsを要求したとしても、実際のバンド幅は100Mbpsになります。

下図は、仮想マシンの設定の編集画面です。ネットワークアダプタを分散ポートグループへ変更し、「シェア」「予約」「制限」を設定します。

 

◆仮想マシンバンド幅のアドミッションコントロール

仮想マシンに十分なバンド幅を確実に割り当てられるようにするため、バンド幅予約とチーミングポリシーにしたがい、ESXiホストおよびクラスタレベルでアドミッションコントロールを実装します。

仮想マシンをパワーオンすると、分散スイッチのNetwork I/O Control機能が、ESXiホストで次の条件が満たされることを確認します。

  • ESXiホスト上の物理NICが、チーミングポリシーと予約に従って、仮想NICに最小限のバンド幅を提供できる
  • 仮想NIC用の予約が、ネットワークリソースプール内の空き割り当て量より小さい

 

<vSphere DRSのバンド幅のアドミッションコントロール>

DRSクラスタ内の仮想マシンをパワーオンすると、vSphere DRSはアクティブなチーミングポリシーに従って、その仮想マシン用に予約されたバンド幅が確保されるキャパシティを持つESXiホストに、その仮想マシンを配置します。下図は極端な例です。

<vSphere HAのバンド幅のアドミッションコントロール>

HAクラスタ内のESXiホストでエラーが発生するかホストが隔離されると、vSphere HAはバンド幅予約とチーミングポリシーに基づき、HAクラスタ内の別のESXiホスト上で仮想マシンをパワーオンします。

 

 

◆まとめ

仮想マシン上のアプリケーションによっては、ネットワークリソースが競合した場合により多くのリソースを割り当てたい、最小限のバンド幅を割り当てたい等のご要望はあると思います。

Network I/O Control バージョン3であれば、これらの要望を仮想NICレベルで満たすことができます。CPUやメモリと同様のコントロール方法ですから、取り組みやすいと思います。予約は仮想マシンがパワーオンできない要因になりますから、その点は注意が必要です。

今回で分散スイッチの投稿は終了です。今後はNSXのご紹介を予定しています。ネットワークは詳しくないと思われているサーバー管理者の方がNSXを検討するなら、を前提に進めたいと考えています。引き続きよろしくお願いします。

仮想スイッチのお作法~分散スイッチの管理②#5~

5回目:仮想スイッチのお作法#5  (分散スイッチの管理②#5)

– Back Number –
#1…仮想スイッチのお作法#1
#2…仮想スイッチのお作法#2
#3…vSphere 6. 5の分散スイッチの機能とアーキテクチャ#3
#4…分散スイッチの管理①#4
#5…分散スイッチの管理②#5
#6…Network I/O Control#6

日本ヒューレット・パッカード株式会社の中川明美です。

5回目は、分散スイッチの障害からのリカバリ方法、vCenter ServerとESXiホスト間のネットワーク接続に問題が生じた場合の対処方法をおもにご紹介します。

◆分散スイッチのネットワーク構成のバックアップとリストア

分散スイッチのネットワーク構成のバックアップとリストアは、次の目的で使用します。

  • vCenter Serverデータベースの破損または誤った設定からの復旧
  • アップグレードでエラーが発生した場合に以前の設定へロールバック
  • 分散スイッチのコピーを作成するためのテンプレート

次の操作により、上記目的を達成します。

  • 非同期でディスク上へ分散スイッチ/分散ポートグループ/アップリンクポートグループ設定のバックアップ (エクスポート)
  • バックアップから分散スイッチ/分散ポートグループ/アップリンクポートグループを復旧 (リストア)
  • 変更後に以前の分散ポートグループ/アップリンクポートグループ設定にロールバック (リストア)
  • バックアップから新しい分散スイッチの作成 (インポート)

◆ネットワーク構成のバックアップ

<分散スイッチのバックアップ>

「設定のエクスポート」メニューで、分散スイッチ/分散ポートグループ/アップリンクポートグループの設定をバックアップします。

ここでは、分散スイッチのバックアップを行います。

「分散スイッチを右クリック → 設定 → 設定のエクスポート」を選択します。

次にエクスポート対象を選択します。

バックアップデータを保存して、終了です。

以前、vCenter Serverデータベースの障害により、複数のVLANを構成した分散スイッチにエラーが発生しました。再作成を前に、導入エンジニアが嘆いていたのを思い出します。

新規作成や構成変更のタイミングで、バックアップを取得しておくことは心の安定を得られますね。様々な設定を構成した分散スイッチのエラーを解消できず、最初から作成するのは心が折れます!

◆ネットワーク構成のリストア

設定ミスを想定し、次の内容に変更しています。

リストアは、分散スイッチ単位/分散ポートグループ単位/アップリンクポートグループ単位で行うことができます。

 

<分散スイッチのリストア>

分散スイッチ単位でリストアする場合は、「分散スイッチを右クリック → 設定 → 設定のリストア」を選択します。次にバックアップファイルとリストア対象を選択します。

<分散ポートグループのリストア>

分散スイッチのバックアップデータから、分散ポートグループのみをリストアすることもできます。リストアしたい分散ポートグループを右クリックし、「設定のリストア」を選択します。

次に、バックアップデータから戻すのか(「設定を次のファイルからリストア」)、正常に動作していた以前の設定にロールバックするのか(「以前の設定にリストア」)を選択します。

バックアップ時の設定に戻されているかは、「設定」 → 「ポリシー」で確認します。下の画面では、先のリストア操作で変更前の状態に戻っています。

 

◆分散スイッチのインポート

バックアップした構成ファイルのインポートから、「新しい分散スイッチの作成」「削除された分散スイッチの再作成」「アップグレードに失敗した分散スイッチの復元」を行うことができます。

また既存の分散スイッチに、エクスポートした分散ポートグループのインポートすることもできます。

ここでは分散スイッチのインポートを行います。データセンターを右クリック、「Distributed Switch」 → 「Distributed Switchのインポート」を選択します。

次に、バックアップファイルを選択します。再作成や復元をする場合は、「元のDistributed Switchとポートグループ識別子を保存します」オプションを選択します。

◆管理ネットワークのロールバックとリカバリ

管理ネットワークの構成ミスのためにvCenter Serverへの接続を失った場合、分散スイッチでは管理ネットワークのロールバックとリカバリを行うことができます。

<ロールバック>

ロールバックはデフォルトで有効の設定になっています。接続を失ったことを検知後、30秒 (デフォルトのタイムアウト値) でロールバックします。タイムアウト値の変更方法はKB2096691を参照ください。

分散スイッチのロールバックは、分散スイッチ/分散ポートグループ/分散ポートに不適切な変更が行われると自動で起動します。

ロールバックを無効にするには、vCenter Serverの詳細設定で「config.vpxd.network.rollback」を「false」にします。

<リストア>

ロールバックを無効にした場合や物理ネットワークの変更によって管理ネットワークに問題を生じた場合、ダイレクトコンソール ユーザーインターフェイス (DCUI) を使用して、管理ネットワークの復旧を行います。

DCUIには次の3つのリストア設定があります。

  • Restore Network Settings
  • Restore Standard Switch
  • Restore vDS

「Restore Standard Switch」「Restore vDS」は、分散スイッチで管理ネットワークが構成されている場合に選択可能になります。管理ネットワークが構成されていない場合はグレーアウト表示になります。

「Restore Network Settings」を選択し、次の画面で<F11>を選択すると、工場出荷時の状態に戻ります。

管理ネットワークの構成エラーから復旧する場合は「Restore vDS」を選択します。次の画面で、ポートバインドの方法を選択します。

分散スイッチを標準スイッチに復元する場合は「Restore Standard Switch」を選択します。

「Restore Standard Switch」を選択すると、IPアドレスを割り当てることができる新しいVMkernelポートと標準仮想スイッチがESXiホスト上に作成されます。分散スイッチのアップリンクは、新しい標準仮想スイッチに移動されます。

<KBのご紹介>

◆分散スイッチのアップグレード

アップグレード対象の分散スイッチを右クリックし、「アップグレード」 → 「Distributed Switchのアップグレード」を選択します。

アップグレードメニューには、他に「Network I/O Controlのアップグレード」「LACPサポートの強化」があります。

< Network I/O Controlのアップグレード>

Network I/O Controlをバージョン3へアップグレードすると、システムトラフィックおよび個々の仮想マシン (仮想NIC) へバンド幅割り当てることができます。#6で紹介します。

<LACPサポートの強化>

バージョン5.1の分散スイッチからバージョン5.5/6.0にアップグレードした分散スイッチで、拡張LACPサポートに変換すると、複数のLAGを作成することができます。

アップグレード前に分散スイッチで基本LACPサポートが有効になっていた場合、拡張LACPサポートへは手動で拡張します。

次の画面で、アップグレードするバージョンを指定します。

 

アップグレード前には、分散スイッチの設定のエクスポートをおすすめします!

 

◆まとめ

今回ご紹介した、「ネットワーク構成のバックアップとリストア」や「管理ネットワークのロールバックとリカバリ」は、バージョン5.1から提供されている機能です。分散スイッチはvSphere 4.0から提供されていますから、こなれた仮想スイッチではありますね。

10Gbpsの物理NICの使用が一般的となり、管理するESXiホストが増設され、分散スイッチを活用する機会が増えてきたのではないかと個人的には思います。

管理ネットワークを分散スイッチで構成するなら、設計も変わってきますよね。分散スイッチで管理ネットワークを構成し、接続が失われた時に慌てた方もいらっしゃると思います。実際に正常に復元するの?と問われたこともあります。事前の復元検証は必須かと思いますが、分散スイッチが提供する復旧機能をぜひ活用いただけたらと思います。

次回は、Network I/O Control バージョン3をご紹介します。