サーバ仮想化とは
サーバ仮想化とは、1つの物理サーバの上に複数の仮想サーバを構築することです。これにより、コスト削減（サーバ物品調達コスト、スペースコスト、電力コストの削減等）や運用性向上（サーバメンテナンス時の容易性やサービス継続性、OSパッチ適用の切り戻し容易性等）といったメリットが得られます。
仮想ホストと仮想マシンと仮想OSと仮想サーバ
ハイパーバイザソフト(VWware ESXi等)をインストールした物理サーバを『仮想ホスト』と呼びます。ハイパーバイザは仮想ホストの上に仮想マシンを作ることができます。仮想OSと呼ばれることがありますがこれは間違いです。
ハイパーバイザは OS を仮想化するのではなく(そもそも OS は物理サーバを抽象化≒仮想化するもの)、物理サーバ上のCPU/メモリ/HDD/NIC等のハードウェアのリソースを切り出して『仮想マシン=VM(Virtual Machine)』を作ります。
その仮想マシン(VM)上に Windows や Linux等のサーバOSをインストールした結果が『仮想サーバ』になるのです。VMにインストールされたOSを『ゲストOS』と呼びます。ハイパーバイザがホスト、OS(スーパーバイザ)がゲストです。
なお、メーカが独自にカスタマイズした仮想サーバのことを『バーチャルアプライアンス(VA: Virtual Appliance)』と呼びます。
通常は作成した仮想マシンにOSをインストールしますが、このバーチャルアプライアンスはメーカが初期セットアップをした状態に作り込んでいるため、仮想ホストから読み込んで起動すれば即使える状態になっています。
ハイパーバイザの機能、役割
前述の通り、ハイパーバイザの主機能の1つは、仮想ホストのCPU/Memory/HDD/NICといったコンポーネントの一部を切り出し、仮想マシンを作ることです。仮想マシンを作成した時点ではOSはインストールされていません。仮想マシンにOSをインストールすることでゲストOSとして仮想サーバが稼働し始めます。
準仮想化と完全仮想化
ハイパーバイザが主にコントロールする対象はゲストOSではなく仮想マシンですが、ゲストOSに全く関与しないわけではありません。例えばハイパーバイザ連携用のユーティリティ(vmware-tools, open-vm-tools等が有名)をゲストOSにソフトウェアとしてインストールすると、仮想環境に最適なIOドライバ(HDD入出力やNICネットワーク入出力等に使われるドライバ)が提供されるなど、仮想マシンとしての性能を高めることができます。この仕組みを『準仮想化(パラバーチャライゼーション)』と呼びます。
準仮想化はハイパーバイザの製品やバージョンに依存してしまうため「別製品や別バージョンのハイパーバイザへの移植性」が損なわれるのがデメリットですが、その代わりにVMを高パフォーマンスにできるというメリットがあります。企業向けに納める場合はたいてい準仮想化です。
対義語として『完全仮想化』がありますが、準仮想化のメリットデメリットが逆になったものになります。
ハイパーバイザの種類による機能の違い
機能の細かい内容についてはハイパーバイザによって異なることが多々あります。例えば仮想ホストにCPUが4コア存在し、その上に vCPU が4コアの VM#1 と、vCPU が2コアの VM#2 があったとします。
KVM の場合は、VM は全てのコアを同時に使わなければなりません。つまりVM#2 が2コアを使っているタイミングでは、残りは2コアしかないので VM#1 は4コア同時に使えません。なのでこのタイミングでは2コアしか動かせません。
これが VMware (ESXi) の場合は、空いているコアは要求する VM に柔軟に割り当てられます。
仕組みとコンポーネント、構成
仮想サーバを構築する際の標準的な構成は以下の通りです。
VM用のCPUとメモリは、前述の通り、仮想ホストが自身のリソースを切り出して提供するのが一般的です。一方VM用のHDDは、共有ストレージで提供されることが多いです。
vMotion(ライブマイグレーション)や VM-HA
前述の「共有ストレージ」を使う構成では、VMをシャットダウンせずに仮想ホストの収容先を変更する『ライブマイグレーション（VMwareで言うvMotion）』が可能となったり、『VM-HAクラスタ』と呼ばれる、仮想ホストの冗長構成を組むことができます。
例えばライブマイグレーションは、1台の仮想ホストをメンテナンスする場合や、CPU/メモリ負荷が偏っているのを解消する場合に役立ちます。
共有ストレージを使わず、仮想ホストのHDDを使ってサーバ仮想化を行うこともできますが、この構成ではライブマイグレーションや VM-HA クラスタ等が使えません。つまり、サーバ仮想化においては、複数の仮想ホストから共通して利用可能な共有ストレージで構成するのがベストプラクティスです。
また、VM へ vHDD を提供する方式は『仮想ディスクファイル』というファイルで提供されることが多いです。例えば共有ストレージを VMFS という VMware 専用のファイルシステムにフォーマットし、その上に test-vm.vmdk といった50GB の仮想ディスクファイルを配置します。するとハイパーバイザの機能で、VM がこの仮想ディスクファイルを50GBの HDD として取り扱うよう設定することができます。
この構成では仮想ディスクファイルを他のファイルシステムにバックアップとしてコピーしたり、他の VM基盤へ移行したりするのが容易になり、運用の利便性が向上します。
他の方式としては『Raw Device Mapping』という方式がありますが、これはブロックデバイス(物理ディスク)をそのまま仮想マシンに接続する方式です。パフォーマンスが出る反面、利便性が損なわれます。よほどパフォーマンスを追及したいときは別ですが、一般的には仮想ディスクファイルで構築することが多いです。
ストレージ vMotion
VMware には仮想ホストの収容替えを行う vMotion だけでなく、共有ストレージの収容替えを行う『ストレージvMotion』という機能もあります。
片方のストレージをメンテナンスする場合や、IO負荷が片方に偏っているのを解消する、といった場合に役立ちます。
ですが高額の共有ストレージを2台置くようなことはあまりしませんし、2台使う場合はディザスタリカバリ用として遠隔地におくことも多く、ストレージvMotion が使える環境はあまり見かけません。
仮想ネットワーク
VM は外部と通信を行うために仮想NIC を持っていますが、仮想NIC はハイパーバイザ上の仮想スイッチに接続されます。つまりハイパーバイザではサーバだけでななくスイッチもエミュレートするのです。
一般的な構成では、物理スイッチとはリンクアグリゲーションと trunk VLAN により接続されます。仮想スイッチには VLAN が定義されており、ハイパーバイザの設定で、どの VM がどの仮想スイッチポート(つまりはどの VLAN）に収容されるかを定義します。
また、ハイパーバイザでエミュレートできるNW機器はスイッチだけではありません。仮想ルータや仮想FW、仮想ロードバランサ等のバーチャルアプライアンスを載せ、仮想ホスト上で柔軟な仮想ネットワークを構築することも可能です。
クラスタ構成
VMware が使えるクラスタ構成は2つあります。1つは前述の『HAクラスタ』、もう1つは『DRSクラスタ』です。
HAクラスタは Essential 等のエントリクラスのライセンスでも利用可能で、もし仮想ホストがシステムダウンした場合、別の仮想ホストから自動で再起動します。
DRSクラスタ は、負荷が偏った場合に自動で vMotion を使って分散配置をしてくれます。この DRS クラスタはハイエンドクラスのライセンスで利用可能です。
HA と DRS はそれぞれ独立した機能ですので片方ON や両方ON にすることも可能です。
スナップショット
サーバを仮想化することで、仮想ホストから見たとき、仮想サーバは1つの仮想ディスクファイルになります(例えばVMwareの場合は.vmdk)。これによりスナップショットの取得が可能となり、運用の利便性が向上します。
例えば仮想サーバの設定変更前にスナップショットを取得し、設定変更作業が万が一うまく行かなかった場合はスナップショットで元に戻す、という対応が可能です。
スナップショットはサーバが稼働中であっても取得は可能ですが、できる限りサーバ停止状態で取得することが望ましいです。どうしてもサーバ稼働中で取得する場合、ハイパーバイザによってはメモリの状態も取得することが可能ですのでそれを実施するほうがよいでしょう。
スナップショットの仕組みについては下記ページをご参照下さい。
リソースの柔軟な移動
先程のライブマイグレーションでは、1つの仮想ホスト上に複数の仮想サーバがあることにより、短期間でのリソース効率化の説明をしましたが、長いスパンでもリソース効率化が出来ます。
つまり、時期によりCPU/メモリ負荷率が異なるサーバが複数あれば、ある時期には『仮想サーバAのリソースを下げ、仮想サーバBのリソースを強化する』という対応をし、そしてその時期が過ぎたら今度はその逆を行うといったリソース効率化も可能です。
『移行が容易で低コスト』というのは半分本当、半分嘘
『仮想サーバを導入すると移行が容易で、かつ低コストである』といった話をたまに聞きます。それはある意味本当で、短期間であちこち動かす必要があるのであれば、それはその通りです。
ただ、長期スパン、つまり、サーバ更改時の移行に関しては、メリットにならないことがほとんどです。というのも、更改時期(5年が1つの目安)には大抵OSやアプリケーションが古くなっており、物理サーバで移行するのとあまり変わらない構築コストが掛かるからです。
仮想化ソフトの種類とソフトウェアベンダ
VMware は現在圧倒的なシェアを誇ります。この人気の理由は、『安定した動作』、『扱いやすいGUI』、『安価なサポート費』の3つでしょう。また、前述の CPU の動作の例もありますが、パフォーマンスの最適化も考慮して作られており、非常に洗練された感があります。
Hyper-Vのデメリットは高価なサポート費(サポート無しという選択も大いにあり)、KVMのデメリットは、不安定性、UIの扱いにくさでしょう。また、いずれもメーカの本業はOSであり、その1機能として作っているためか、ハイパーバイザ専門の VMware に比べて細かい機能で見劣りします。
Xen は VDI分野では聞きますが、サーバ仮想化にはあまり使われません(正直言うと使ったことないから分かりません)。
OpenStack は話題にはよく上がりますが、どちらかというと Amazon AWS や Microsoft Azure のような、IaaS/PaaS事業者が扱う前提の管理機能が充実していますので、エンタープライズでは機能を活かしきれないばかりか、場合によっては不都合すら出てくるように思えます。
vCenter とは
vCenter は仮想ホストや VM などの『VMware のコンポーネント全体を一元管理する機能を持つサーバ』です。仮想ホストと異なる物理サーバとして単体で構築することも多いですが、仮想ホスト上に VM として構築することも可能です。
vCenter はもし障害等でシャットダウンしても、VM は影響を受けずに稼働し続けることが可能ですが、一元管理する機能が失われますので、管理系操作に不都合が生じます。(ただし、ESXi に個別にログインして個別の操作は可能です。)
vCenter は共有ストレージも「ハイパーバイザ」経由で一定の管理はできますが、管理できる内容はHDDボリュームに関する取り扱いくらいです。つまり共有ストレージの「ハードウェアの状態確認」等の踏み込んだ管理はできないのです。
共有ストレージは(必須ではないにも関わらず、)可用性や運用性を考慮したときにはサーバ仮想化の重要なコンポーネントです。その管理が個別になるのは良くないでし、さらに言うと、もともとソフトウェアを生業としたメーカの製品が、サーバや共有ストレージというハードウェアメーカの製品と組み合わせる必要がありますので、問題発生時には切り分けが複雑になりがちです。
こういった問題のソリューションとして出てきたのが次に紹介する『HCI (ハイパーコンバージドインフラ）』です。
HCI (ハイパーコンバージドインフラ)とは
HCI とは、仮想環境に必要なコンポーネント(ハードウェア/ソフトウェア両方)を1台のアプライアンスに集約したものを指します。VMware を引き合いにして平たく言うと、vCenterで集約出来ていない「共有ストレージ」の管理機能を盛り込んだ上に、ソフトウェアとハードウェアを1つのメーカが組み合わせて製品化したものです。
これにより、管理を完全に統合できることに加え、1メーカによる一元的な保守サービスを受けることができます。
具体的には、3台の HCI アプライアンス製品(以降HCI)で仮想環境を構築した場合、それぞれが仮想ホストと同じ振る舞いをしつつ、それに加えて3台の HCI に搭載されたHDD/SSD があたかも1台の共有ストレージかのように振る舞わせる仮想的な共有ストレージが作られます。以下に Nutanix の例を示します。
なお、VMware もこの HCI の波が出来る前から、仮想ホスト上のローカルディスク達を1台の共有ストレージに見せかける vSAN という機能を提供しています。
サーバ仮想化とクラウドとの違い
クラウドとはクラウドコンピューティングの略で、『利用者が、実態を理解していないサーバ群に、利用者が望むサービスを要求し、サーバ群からサービス応答が戻ってくる』というサービス利用形態を指す言葉です。
このクラウド技術は仮想サーバありきではないですが、仮想サーバを使うケースが非常に多いため、用語がごっちゃになりがちですが、根本的に別物です。