従来のサーバー
従来のサーバーでは、クライアントPCと同様にOSを直にインストールし、
アプリケーションを稼働していました。
アプリケーション間の影響を考慮して、機能毎にハードウェアを用意することが一般的でした。
アプリケーションを稼働していました。
アプリケーション間の影響を考慮して、機能毎にハードウェアを用意することが一般的でした。
コンテナ型
OS上にコンテナ化するための機能をインストールします。
そのコンテナ上で各アプリケーションを動作させることで、
管理性・アプリケーション間の影響を減らすことが可能となりました。
そのコンテナ上で各アプリケーションを動作させることで、
管理性・アプリケーション間の影響を減らすことが可能となりました。
ハイパーバイザー型
初めにハイパーバイザーをインストールします。
その上に仮想マシンという形でOSをインストールしアプリケーションを稼働します。
複数の仮想マシンを稼働させることが可能となりました。
その上に仮想マシンという形でOSをインストールしアプリケーションを稼働します。
複数の仮想マシンを稼働させることが可能となりました。
比較
タイプ | メリット | デメリット |
---|---|---|
従来のサーバー | 簡潔 オーバーヘッドなし |
ハードウェアの台数 OSの台数 電気代 |
コンテナ型 |
アプリケーション管理 ハードウェアの台数 |
アプリケーションが対応するOSの制限 オーバーヘッドあり |
ハイパーバイザー型 | 耐障害性 ハードウェアの台数 |
OSの台数 オーバーヘッドあり |
見解
仮想化の開発当初は、導入によりアプリケーションのレスポンス低下が問題とされていました。
しかし、ハードウェアや仮想化機能の性能は年々増加傾向にあり、リソース自体に余裕のあるものとなってきました。
複数のアプリケーションやOSを動作させても、体感的には変わらない程度の性能が確保されつつあります。
しかし、ハードウェアや仮想化機能の性能は年々増加傾向にあり、リソース自体に余裕のあるものとなってきました。
複数のアプリケーションやOSを動作させても、体感的には変わらない程度の性能が確保されつつあります。
特にハイパーバイザー型では、仮想マシンのデータを仮想ディスクと呼ばれる単一のファイルで管理します。
また、仮想ディスクを共有ストレージ上に保存して、ESXiから仮想マシンを起動することが可能です。
また、仮想ディスクを共有ストレージ上に保存して、ESXiから仮想マシンを起動することが可能です。
冗長構成・ハードウェアのメンテナンス・OSの一元管理など、
時間や場所による制約を大きく改善することができます。
障害について
ESXiホストをクラスタと呼ばれるグループに入れることで、以下のような機能が利用できます。
機能 | 停止時間 | 内容 |
---|---|---|
HA | OS再起動時間分 | 障害発生時に、別のESXiホストで再起動する。 |
FT | 無停止 | 仮想マシンのディスク状態を常に同期することで、 障害発生時にESXiホストを切り替える。 |
※上記は、HAによる障害発生時の動作説明図。
VMware社の試み
前項では、ハイパーバイザーを活用することで仮想マシンを複数起動できると紹介しました。
この構成においてVMwareではハイパーバイザー(ESXi)を一括して管理する製品(vCenterServer)を用いることが多く、今では必須とされている要素になります。
この構成においてVMwareではハイパーバイザー(ESXi)を一括して管理する製品(vCenterServer)を用いることが多く、今では必須とされている要素になります。
<具体的な機能>
・仮想マシンの一元管理
・ハイパーバイザー、ストレージ間の移行
・障害発生時のホスト切り替え
等・・・
まだ、制限が多く実用化には時間がかかりそうですが、
複数のvCenterServer間や更には物理的に離れた拠点間ネットワーク越しに、
上記の機能を実現できるよう開発が進みつつあります。