• TOP > 仮想化アーキテクチャ > System Center
  • SCVMM 機能一覧

System Center Virtual Machine Manager (SCVMM)

SCVMM 自身も WSFC 対応された。

SCVMM の主要な役割を提供する。

SQL Server で構成され、SCVMM の構成情報や管理状態情報を格納する。

VMM 管理サーバーと接続して、仮想マシンや物理ホストの管理を行う管理者用の GUI ツール。

エンドユーザー向けの Web サイト。

移行メモ: セルフサービス ポータルは SCVMM 2012 R2 で廃止されており、
後継は App Controller（これも提供終了）、
現在は Windows Azure Pack や Azure 側のポータルが
同等の役割を担う。本ページ末尾の
今後の機能拡充で著者が予想している方向に実際に進んだ。

• VHD
• VM テンプレート
• サービス・テンプレート
• プロファイル
• ISO イメージファイル
• インストールファイル
• スクリプト

等の仮想マシン作成に必要なリソースを一元管理する。

• VMM ライブラリの管理
  http://technet.microsoft.com/ja-jp/library/cc764248.aspx

  SCVMM ではライブラリ化しないとテンプレート VHD 等を使用できない。

事前に仮想マシンのテンプレート（VHD）を用意しておき、
ユーザから要求があった場合や障害時などに、動的に仮想マシン（VHD）を作成する。

• 概要

  • 動的にホスト・ゲストの利用状況を判断し、
    負荷に偏りがある場合は、最適な環境へ仮想マシンを移動して負荷を分散する。
  • 仮想マシンの移動の仕組みはライブ・マイグレーションを使用している。

• サポート

  • SCOM と SCVMM の組み合わせでサポート。
    • SCOM の PRO と呼ばれるリソース最適化機能を利用
    • リソース使用状況に問題があった場合、「PRO ヒント」を SCVMM に通知

動的最適化（DO：Dynamic Optimization）
自動ワークロード分散（PRO 機能）の後継

設定内容

• 動的最適化の有効化

• 移行の間隔（既定は 10 分間隔）

• リソースの閾値

• 電力最適化の有効化

• VMM での動的最適化と電力の最適化の構成
  http://technet.microsoft.com/ja-jp/library/gg675109.aspx

  ライブ マイグレーションをサポートするホスト クラスター内で負荷分散を実行。

補足（PRO と DO の違い）: 両者は依存関係が異なる。

• PRO — SCOM の監視結果に依存する（SCOM が必須）
• 動的最適化（DO） — SCVMM 単体で動作する

本ページが「後継」と書いているのはこの点で、
SCOM を導入していない環境でも負荷分散が使えるようになった、という改善である。
「電力最適化」は、負荷が低い時間帯にホストを集約して
空いたホストを停止する機能。

ホスト OS ノードの追加に迅速に対応する。

ホスト クラスター等の追加にも対応とのこと。
クラスタを追加か？クラスタ内に追加か？は不明。

1. アウトオブバンド管理（OOB）のサーバを検出し、
   PXE ブート機能を使用してベアメタル・サーバが再起動される。
2. ベアメタル・サーバは、管理サーバの役割として、VMM に追加された WDS サーバを検索する。
   WDS サーバには VMM プロバイダが搭載され、このプロバイダが VMM プロビジョニング・ツールを
   使用して起動されたベアメタル・サーバからの PXE 要求を管理する。
3. WDS サーバ上の VMM プロバイダは、VMM サーバとして接続して、
   ベアメタル・サーバに管理対象ホストを展開する権限があることを確認する。
4. ベアメタル・サーバが VMM で認証されると、Windows PE イメージがこのサーバにダウンロードされる。
   このイメージには、ベアメタル・サーバへの OS システムの展開を制御する VMM エージェントが含まれる。
5. VMM エージェントは、ファームウェアの更新、RAID の構成および、
   パーティションの構成とフォーマットを指定できる汎用的なコマンド・スクリプトを実行する。
6. 仮想ハードディスク（VHD）が、ライブラリからホスト OS 上にダウンロードされる。
   よって、ベアメタル展開においては VHD からのブートが使用される。
7. ホスト特有のドライバがある場合は、ライブラリ・サーバからダウンロードされる。
8. 展開後のカスタマイズが実行される。カスタマイズは Sysprep のセットアップ・プロセスを使用し、
   サーバ用の設定（サーバ名など）や、ドメイン参加などのオプションがある。
9. Hyper-V の役割をインストールし、有効化する。

移行メモ（正誤）: 元ページの「PxEブート」「PxE要求」は
正しくは PXE（Preboot eXecution Environment）、
「VMMプロビジョニンング・ツール」は「プロビジョニング・ツール」、
「WindwosPEイメージ」は「Windows PE イメージ」の誤記と判断し、修正した。

補足（OOB 管理の前提）: 手順 1 の「アウトオブバンド管理（OOB）」は、
IPMI / DCMI / SMASH といった管理インターフェイス（iLO、iDRAC 等）を指す。
ベアメタル展開は、SCVMM がこれらを経由して
電源投入と起動デバイスの指定を遠隔で行えることが前提になるため、
ハードウェア側の要件確認が必要になる。

• Hyper-V 2012 からネットワーク仮想化（NVGRE）もサポートする。

  • NVGRE：Network Virtualization Generic Routing Encapsulation
  • 参考：Hyper-V ネットワークの仮想化

• SCVMM では、ネットワーク設定を抽象化して扱う。
  これにより、ネットワーク仮想化なども管理しやすい。

・VM（仮想NIC）

↓・↑

・VMネットワーク（抽象的なもの）

↓・↑

・論理ネットワーク（ファブリック）

↓・↑

・仮想スイッチ（外部）

↓・↑

・物理ネットワーク

• 仮想マシンの接続するネットワークである。
• ネットワーク仮想化しているとは限らない。

論理ネットワーク（ファブリック）

• 物理リソースへのマッピングの役割を担う。
• VM ネットワークである仮想スイッチ（外部）と接続する。

以下を回収・配布（チェックイン・チェックアウト）。

• IP アドレス範囲

  • DHCP と異なり IP アドレスを静的に配布する。
  • 以下の両方をターゲットに出来るがプールは別になる。
    • Provider Address
    • Customer Address

• TCP/IP オプション

  • 既定のゲートウェイ・アドレス
  • DNS サーバ・アドレス
  • DNS サフィックス
  • WINS サーバアドレス

補足（Provider Address と Customer Address）: これは
ネットワーク仮想化（NVGRE）で使う 2 層のアドレス体系を指す。

• Customer Address（CA） — 仮想マシンが認識する IP（テナントごとに重複可）
• Provider Address（PA） — 物理ネットワーク上で実際に流れる IP

NVGRE は CA のパケットを PA 宛にカプセル化して転送するため、
プールを分けて管理する必要がある、というのが本節の趣旨である。
なお NVGRE は後続の Windows Server で VXLAN に主流の座を譲っており、
Azure 側も VXLAN 系の方式を採っている。

今後サポートされる見込み。

物理スイッチと SCVMM が連携可能になれば、
SCVMM から各スイッチ（Top of Rack）の管理も可能になる。

移行メモ: この予想は概ね実現し、
Windows Server 2016 の SDN（ネットワーク コントローラー、
ソフトウェア ロード バランサー、ゲートウェイ）として提供されている。
SCVMM はその管理フロントエンドとして機能する。

VMW と比べると、VMM では、後からテンプレートに
カスタマイズを組み込める（モジュール化されるイメージ）。

これらはライブラリ上に配置する。

移行メモ: 文中の「VMW」は VMware（vSphere / vCenter）を指す略記。

固有情報（SID やドライバ情報など）を削除

• Sysprep

VM に割り当てる H/W の構成情報で、
テンプレートから VM を作成する際の既定値となる。
（ラージ・インスタンス、スモール・インスタンス的な構成情報）

Sysprep 応答ファイルとして機能する。
Sysprep による Windows ミニセットアップの処理を自動化する。

• VM 展開後のドメイン参加まで自動化することができる。
• 導入されていない機能や役割を展開時に導入することもできる。

System Center 2012 では、仮想マシンの展開に留まらず、
システム・サービスとしての展開をサポートする（PaaS 風機能）

SQL Server インスタンスを展開後に自動作成する。
（SQL Server 2008 R2 から）

• SQL Server データ層アプリケーション（SQL DAC）
  DAC は、アプリケーションが使用する
  データベースとインスタンスの全てのオブジェクトを含む。

• 仮想アプリケーション（Server App-V による実装）
  http://technet.microsoft.com/ja-jp/magazine/jj819422.aspx

• Web アプリケーション（IIS Web Deploy 対応パッケージ）
  Microsoft Web 配置ツールを使用して Web アプリケーションをパッケージ化し展開する。

  • Web ベース・アプリケーション・コンテンツ
  • Web サイト
  • 証明書
  • レジストリ

• スクリプト

以下を組み合わせてサービス・テンプレートを構成できる。

• サービス・テンプレート
  • VM テンプレート
    • VHD ファイル（Sysprep 済み）
    • H/W プロファイル
    • ゲスト OS プロファイル
  • SQL Server プロファイル
  • アプリケーション・プロファイル

また、このサービス・テンプレートを複数組み合わせることで、
複数の VM から構成されるサービスを構成できる。

補足（この考え方の行き先）: 「テンプレートを組み合わせて
複数 VM から成るサービスを一括展開する」という発想は、現在では
Infrastructure as Code（Azure の ARM テンプレート / Bicep、Terraform）
として一般化している。
また、アプリケーション・プロファイルが担っていた
「VM の中にアプリを流し込む」部分は、
コンテナ技術によって
イメージそのものにアプリを含める方式へ置き換わった。

最新の VMM は、NIC 定義や分類、ホストのベアメタル展開、
そしてフェイル・オーバ・クラスタの管理まで管理できるようになったため、

VMM を利用して

1. 物理マシンへの OS の自動展開
2. Hyper-V の追加
3. VMM 配下にホストを登録
4. クラスタ環境へのホスト追加

を自動化することが可能になった。

運用コスト削減や時間削減を考えると、
このベアメタル展開が主流になる可能性がある。

今後、

• クラウド・ポータル
• 仮想環境の管理機能
• それぞれのモジュール

などが連動して拡張されていく（e.g. NW スイッチの Adapter）。

• クラウド・ポータル

  • Azure Pack
  • App Controller

• System Center

  • SCVMM
  • Service Provider Foundation

• 機器

  • Adapter
  • 機器

• 余談

  • ポータル ＋ Service Provider Foundation
    （≒ OpenStack、CloudStack のコア部分の規格）

補足（実際にどうなったか）: 著者の予想した方向のうち、

• Windows Azure Pack はオンプレミスに Azure 風ポータルを載せる製品として提供されたが、
  後継は Azure Stack（現在の Azure Local）に移った。
• App Controller は提供終了。
• 一方、「オンプレミスの基盤をクラウド側のコントロール プレーンから管理する」
  という方向自体はさらに進み、現在は Azure Arc が
  オンプレミスのサーバ・Kubernetes・データ サービスを
  Azure ポータルから一元管理する形になっている。

つまり、著者が「ポータル＋基盤管理が連動して拡張される」と見た構図は
オンプレミスの製品としてではなく、クラウド側から降りてくる形で実現した
と言える。

• 本 Wiki 内
  • System Center
  • Hyper-V
  • Hyper-V ライブ・マイグレーション
  • Hyper-V 高可用性オプション
  • Hyper-V ネットワークの仮想化
  • P2V

Tags: インフラストラクチャ, Windows, 仮想化