検索
連載

明らかになった「Hyper-Vコンテナー」の正体(1)――その仕組みと管理方法vNextに備えよ! 次期Windows Serverのココに注目(37)(1/2 ページ)

マイクロソフトは2015年11月20日(日本時間)、「Windows Server 2016 Technical Preview 4(TP4)」を公開しました。2015年8月のTP3ではコンテナー技術が初めて搭載され、「Windows Serverコンテナー」を評価できるようになりました。TP4ではいよいよ「Hyper-Vコンテナー」のお披露目です。

PC用表示 関連情報
Share
Tweet
LINE
Hatena
「vNextに備えよ! 次期Windows Serverのココに注目」のインデックス

連載目次

Windows Serverコンテナーについてのおさらい

 Windows Server 2016には「Docker」互換のコンテナー技術が搭載され、「Windows Serverコンテナー」と「Hyper-Vコンテナー」の2種類のWindowsコンテナーの作成と実行が可能になる予定です。

 Windows Server 2016におけるコンテナー技術のコアサービスである「Containers」およびWindows Serverコンテナーについては、2015年8月にリリースされたWindows Server 2016 TP3で初めてプレビューが提供されました。また、オープンソースのDockerにはWindows Server 2016のContainersのサポートが組み込まれ、DockerコマンドおよびDocker APIによるコンテナーの管理も可能になっています。これらの機能については、本連載で詳しく説明しています。

 Windows Server 2016 TP4では、Hyper-Vコンテナーの初めてのプレビューが提供されています。本題に入る前に、ちょっとだけWindows Serverコンテナーの仕組みをおさらいしておきましょう。

 Windows Serverコンテナーは「WindowsServerCore」というコンテナーイメージがベースとなっており、Windows Server 2016のServer Coreインストールベースのアプリケーション実行環境をコンテナーとして提供します。LinuxベースのDockerのコンテナー技術と同様、Windows ServerコンテナーはWindows Serverコンテナーホストのカーネルを共有し、コンテナーイメージの「WindowsServerCore」がOSのシステムファイルのバイナリやライブラリを提供して、コンテナー内で変更された差分だけがコンテナーごとのディスク領域に書き込まれます(図1)。

図1
図1 Windows Serverコンテナーの実行イメージ。コンテナーはカーネルを持たず、コンテナーホストのカーネルを共有している

 コンテナー技術は、上の図1のような仕組みにより、従来型の仮想マシンの仮想化技術よりも素早くアプリケーション実行環境をデプロイしたり、短時間でコンテナーを起動したり、少ないリソースでコンテナーを実行したりできます。Windows Serverコンテナーの場合、コンテナーはコンテナーホスト上で実行される“一つのプロセス”にすぎません。それを、コンテナーごとに分離されたアプリケーション実行環境に見せているのです(画面1)。

画面1
画面1 1つのWindows Serverコンテナーは、コンテナーホスト上で実行される一つのプロセス(CExecSvc.exe)にすぎない

2種類のコンテナー、実は見た目も操作方法もあまり変わりません

 Windows Server 2016 TP4で初めてHyper-Vコンテナーに触れるまで、筆者は大きな誤解をしていました。

 筆者は、Hyper-Vコンテナーを「WindowsまたはLinux仮想マシンを実行可能な軽量なHyper-V環境」と想像していたのですが、実は全く異なるものでした。Hyper-Vコンテナーとは、一言でいうなら、「Hyper-Vを利用することで、コンテナーホストや他のコンテナーとの隔離度をより高めたコンテナーのデプロイのオプション」になります。

 また、Windows Server 2016 TP4のHyper-VとWindows 10 バージョン1511(およびWindows 10 Insider Previewビルド10565以降)のクライアントHyper-Vでは、「Nested Virtualization」(入れ子構造の仮想化、Nested Hyper-Vとも呼ばれる)がサポートされましたが、これはHyper-Vコンテナーに必須の要素技術であると思っていました。これも大きな誤解でした。Hyper-VコンテナーにNested Virtualizationは必須ではありません。この点については次回に説明します。

 Hyper-Vコンテナーは、Hyper-Vのハイパーバイザー環境に完全に依存します。Hyper-Vコンテナーのコンテナーイメージ「NanoServer」はNano Serverをベースとしたもので、Hyper-Vの仮想マシン環境で実行され、コンテナーごとのアプリケーション実行環境を提供します。Windows Serverコンテナーとは異なり、コンテナーホストとカーネルを共有することはありませんし、他のコンテナーとも完全に分離されます(図2)。

図2
図2 Hyper-Vコンテナーの実行イメージ。Windows Serverコンテナーとは異なり、コンテナーホストとカーネルを共有しない

 コンテナーの作成や実行、イメージの作成、エクスポート/インポートなどは、Windows Serverコンテナーとほとんど同じ操作で行えます。異なる点があるとすれば、Windows PowerShellの「New-Container」コマンドレットでコンテナーを作成する際、コンテナーイメージとして「NanoServer」(または「NanoServer」イメージから作成したカスタムイメージ)を指定することと、「-RuntimeType HyperV」パラメーターを追加することだけです。Dockerコマンドを使用する場合は、コンテナーイメージとして「nanoserver(全て小文字)」(または「nanoserver」イメージから作成したカスタムイメージ)を指定して、「--isolation=hyperv」パラメーターを追加します。

 Windows Serverコンテナーはコンテナーホスト上の一つのプロセスでしたが、Hyper-VコンテナーはHyper-V仮想マシンと同様、コンテナーごとの「仮想マシンワーカープロセス(wmwp.exe)」で実行されます(画面2)。ただし、コンテナーホストからは、Hyper-Vの通常の仮想マシンとしては見えません。例えば、「Hyper-Vマネージャー」には表示されません。

画面2
画面2 Hyper-Vコンテナーは、コンテナーごとに「仮想マシンワーカープロセス(wmwp.exe)」で実行される

 Hyper-Vコンテナーは、Windows Serverコンテナーのようにコンテナーホストとカーネルを共有するというコンテナー技術とは矛盾しており、本質的には従来型の仮想マシンベースの仮想化技術と変わりません。Windows Serverコンテナーと同じ操作性で、仮想化ベースの隔離環境を提供するのがHyper-Vコンテナーであり、それにはNano Serverの役割が大きく関係しています。

 前出の画面1と画面2で、それぞれのコンテナーのメモリ使用量を比べてみてください。Hyper-Vコンテナー(前出の画面2)はWindows Serverコンテナー(前出の画面1)の500倍ほどメモリを多く使用していますが、それでも300MB以下です。Windows Server 2016の最小メモリ要件は512MBですので、通常の仮想マシンと比べれば、圧倒的に少ないメモリで動作しています。Hyper-Vコンテナーは、Nano Serverがあればこそ実現できたといってもよいのではないでしょうか。

Copyright © ITmedia, Inc. All Rights Reserved.

       | 次のページへ
ページトップに戻る