VMware vSphere の構築や学習の結果、再度サーバーの仮想化について、簡単ですがまとめてみました。
サーバーの仮想化とは？
コンピュータのリソースを抽象化してプール化し、1つの物理サーバー上で複数の仮想サーバーを動かすことができるようにすることを「サーバーの仮想化」と言います。
サーバー仮想化のメリット
一番最初に思い浮かべるのは
リソースの「効率化」
です。
現場で数十台・数百台のサーバーを構築・運用監視していると分かりますが、ほとんどのリソースは利用されていません。
100台中95台のサーバーの CPU 使用率が 0.5％ 程度で、残りの 5台の DB サーバーだけ常時 90％なんてことはよくあります。
サーバーを仮想化せずに物理サーバーを中心にしている企業がたまにありますが、非常にもったいなく感じます。
かと言って、最適な構成で物理サーバーを構築できるかと言うと、どうしてもオーバースペック的な設計をせざるを得ないです。
計算上は CPU 1個でも充分なんだけど、CPU 1個にして構築した後に、万が一負荷が高まってサービスが止まった場合、責任うんぬんではなく、そもそも CPU の増設が簡単にできないということです。
スケールアウト（台数を増やす）にせよ、スケールアップ（CPUをハイスペックなものに入れ替える、増やす）にせよ、簡単にできません。
しかし「仮想環境」なら簡単に CPU のコア数を増やすことができます。
逆にリソースが余り気味なら、簡単に CPU のコア数を減らすこともできます。
物理サーバーの場合はこのように簡単にスペックを変更することができません。
しかもハイスペックだからと言って、売り上げが伸びるわけでもありません。（逆に低スペック過ぎてレスポンスが返ってこないようだと顧客の信頼が失われて売り上げが落ちることはあります）
そのためサーバーを仮想化することで革新的にサーバーのリソースを有効活用できるようになりました。
仮想化のテクノロジーについて
いくつかの仮想化のテクノロジーについて考察しました。
大きく分けて「仮想化のテクノロジー」は、以下の3点に集約できます。
- リソースの分割と共有
- コンピュータのカプセル化
- ハードウェア非依存
リソースの分割と共有
1つのリソース（1台のハイスペックな物理サーバー）を分割して、各仮想マシンがリソースを効率的に利用することができます。
また1つの巨大なリソース（ディスク20TB、ネットワーク帯域幅 10Gbits/s など）を共有して効率よくリソースを利用することができます。
更に細かく設定することで、各仮想マシンが利用するリソースを完全に独立化・隔離化することができます。
つまり、1台の仮想マシンの暴走が他の仮想マシンのパフォーマンスに影響が出ないようにすることができます。
VMware vSphere では細かく設定することで可能です。
Linux カーネル自体をハイパーバイザー化する KVM（Kernel-based Virtual Machine）でも可能かもしれませんが、情報が少なすぎるのと、定期的にメンテナンスやバージョンアップやバグ修正が行われているようには見えないため、検証環境やテスト環境でしか使えないです。
コンピュータのカプセル化
仮想マシンを1つのファイルとして「カプセル化」しています。
そのため、日々の運用でバックアップやクローンを簡単に作ることができます。
（単純にファイルをコピーすれば同一マシンが誕生する）
VMware vSphere ではテンプレートの仮想マシンを1台作成しておいて、新規仮想マシンをテンプレートからデプロイすれば、数十秒で MySQL サーバーや Apache サーバー、Nginx サーバーなどが構築できます。
仮想マシンの IP アドレスの設定や自動起動などをプログラムから実行すれば、数十秒でサービスインも可能です。
ハードウェア非依存
仮想マシンには、仮想 CPU や 仮想メモリが搭載されていますが、それらの仮想ハードウェアは抽象化されています。
そのため、IBM のサーバー上で稼働している仮想マシンを、DELL 製のサーバーに移行しても問題なく利用することができます。
NIC のドライバが合わなくてネットワークに接続できないとか、マザーボードが古すぎて最新のファームウェアが入手できない等のトラブルはなくなります。
仮想マシン単体ではハードウェアに非依存なので、物理サーバーが古くなったら、新しい物理サーバー上に引越するのも簡単です。
VMware vSphere 環境の場合は、複数台の ESXi ホスト（物理サーバー）で運用するのが通常ですが、仮に1台の ESXi ホストでハードウェア障害が発生したとしても、すぐに他の ESXi ホスト（物理サーバー）に移動することができるので障害には強くなります。
たとえば、物理サーバーに Oracle でデータベースサーバーを構築して顧客の大事なデータを管理している環境では、サーバーを再起動するために半年前から準備をするなど大変な作業をしていました。
ましてや物理サーバーの入れ替えとなったら、1年がかりの巨大プロジェクトになり、プロジェクトマネージャ（PM）が過労死するのではというくらいの大変さでした。
しかしサーバーを仮想化することにより、スナップショットを取れたり、クローンを作って試験をしたり、バックアップをとることが簡単にできるようになったため、メンテナンスのハードルが下がりました。
サーバーを仮想化することで構築や日々の運用が変わる
サーバーを仮想化することで以下のように構築や日々の運用が変わります。
短時間で高品質のサーバーが構築可能になった
1台の仮想マシンを設計して構築して試験をして、問題がなければその仮想マシンを「テンプレート化」します。
その後は、新規仮想マシンを構築する際は、そのテンプレートから構築すれば、同じ設定・同じ品質（例えば同じファイアウォールの設定、同じカーネルのチューニング、同じネットワークの設定など）の仮想マシンが短時間で構築できます。
例えば、50台の物理サーバーを3人で構築した場合、かなり漏れやミスや出てくると思います。
Excelで作成して、白黒で印刷した手順書を片手に、それぞれがコマンドを実行したり、Windows サーバーならマウスを動かしてクリックして設定を入力していきます。
その設定項目が1台につき300項目くらいあるとすれば、何かしら漏れや設定ミスが出てくるであろうことが想像つきます。
構築後に数回テストをしても最終的に同じ品質のサーバーを構築するのは無理があるでしょう。
どうしても企業は経済活動をしているため、時間と費用に限りがあります。
そのため、どこかしらで妥協する必要があります。
妥協しないと1人あたりのエンジニアの1ヶ月の残業時間が数百時間というとんでもない数字になってしまいます。
実際国内の大手 SIer ではそれくらいの残業時間はよくありました。（今では 36 協定（サブロク協定）の厳守が言われるようになりました）
しかしサーバーを仮想化することで、効率よくサーバーの構築と運用が行われるようになります。
バックアップ＆リストアが簡単
物理サーバーのバックアップを取ることは簡単です。
コマンドでデータをコピーすればいいですし、有償のバックアップツール（Backup Exec、ArcServeなど）も利用できます。
問題は「リストアができない」ことです。
リストアするだけならできるかもしれませんが、様々な条件があります。
- 同じ物理サーバーにリストアする場合 ← 失敗したらどうする？元の状態に戻せるか？
- 他の物理サーバーにリストアする場合 ← 全く同じ構成の物理サーバーが入手できるか？マザーボード、ディスク、ファームウェアなど合わせられるか？
物理の場合は、かなりのリスクがあります。
確実にリストアしようとすれば、コストもかかります。
トラブルが発生した際の「スキル」や「サポート」などかなりの一大プロジェクトになります。
しかし仮想マシンの場合は単なるファイルなので、最低限 ESXi のバージョンが同じなら（バージョンが異なっても可能な範囲なら）簡単に復元できます。
スナップショットも数十秒で取得できますし、オンラインでメモリを含めてのスナップショットも可能です。
（仮想マシンの場合はメモリの内容もファイルとして管理されています）
物理サーバーと異なり仮想マシンの「バックアップ」と「リストア」はかなりハードルが低く、現場のエンジニアにとって日々の運用監視の業務内容がガラリと変わるくらいです。
うまく仮想マシンのメリットを利用すれば監視サポートの要員を24時間365日確保する必要はなく、平日の9時～17時だけの対応でも十分サービスを提供できるくらいに「冗長化」と「負荷分散」が可能になります。
ハードウェアのリプレイスが簡単
ハイパーバイザーさえ構築できれば、その上に搭載されている仮想マシンの移行（マイグレーション）は簡単です。
例えば、VMware vSphere 環境なら、ESXi ホストを構築すれば簡単にクラスタに組み込むことが可能ですし、vMotionで簡単に仮想マシンを他の ESXi ホストに移行することができます。
しかも vMotion ならオンラインで移行が可能なので、サービスを停止する必要がありません。
物理サーバーのリプレイスの場合は一大プロジェクトになるのに対し、仮想マシンの場合はそもそもユーザーも気が付きません。
そのためメンテナンスが大幅に負荷が少なくなり、リプレイスのトラブルがなくなります。
災害対策（ディザスタリカバリ）が現実になる
今まで災害対策と言っても「非現実的」な話だったと思います。
今まで議論では
「データセンターを複数持って、それぞれに優秀で自己判断できる正社員のエンジニアを配置して、東京に大災害（地震・テロ・戦争等）が発生した場合は切り替えて、サービスの提供を続けて売り上げを伸ばし続ける・・・」
など、ほぼ 100％失敗しそうなプランを立てていた（もしくは立てらなかった）と思います。
しかしサーバーの仮想化により、具体的な議論ができるようになりました。
データセンターを複数持ち、毎日バックアップを取ることで、災害時には簡単にリストアすることができます。
VMware vSphere の場合は、vSphere Replication で異なるデータセンターにレプリケーション（複製）することができます。
ただ複製だけしても復元できなければ意味がないため、「リカバリ」の手順も確立しています。
ただし「リカバリ」の手順はかなり複雑化することも予想されるため、「Site Recovery Manager」を利用して、リカバリ手順を自動化することも可能です。
コメント