このArticleではサーバ統合をはるかに超えた仮想化の先進的な適用についてMak King氏が説明をおこないます。仮想サーバにディベロッパを集めるそのテクニックとメリットについて知れば、仮想化が制約のある一般的な統合とは別物であると分かります。それに加え、また勝ち組になろうという目的が全くなかったとしても、彼の記事に書かれたアプローチは明らかに「環境に優しいコンピューティング」となります。
もしこのアプローチや似たような開発環境を実現する上で彼のアドバイスや助けが必要であれば info@ShiftMETHOD.com (メール)までコンタクトしてください。
はじめに
おそらく、この数年の間IT業界の仕事に携わっている方であれば仮想化についてはご存知のことでしょう。仮想化の利点に対する世間の号令はほとんど騒音のようになっています。支持者たちはそれがITにとって過去10年で一番の恩恵だと言います。仮想化は機器から解放し、費用を節約し、惑星を一列に並べたり貧窮する大勢の人々に食料を与えたりすること以外は基本的になんでもできるのだといいます。果たして仮想化は期待通りのものなのでしょうか？それを実現した後に得られる本当のメリットは何なのでしょうか？私は勤務するNYCE Payments Networkの開発部署において仮想化を導入する中で現実的な教訓をいろいろ得ました。当社はMetavanteグループの一員で、NYCEは8900 万枚以上のカードの口座と200万以上のATMおよび全国のPOSをつなぐ電子決済ネットワークです。NYCEは、消費者がどこでも必要な時に自身の資金へ安全かつリアルタイムにアクセスできるサービスを提供します。そのため、当社のインフラとして選択するシステムでは可動時間、信頼性、スケーラビリティがクリティカルなものになります。
著者のバックグラウンド
IT 業界での仕事は12年になり、自分ではビジネスの問題を解決するために新しい技術を導入することにかけてはかなりのセンスがあると思っています。もちろん技術の進歩に付いていくのは簡単なことではありませんし、そういう意味では仮想化もそうです。私が実際に仮想化に触れたのは、NYCEの他の場所では 2001年から仮想化が導入されていたにもかかわらず、2つほどのLinux系デスクトップで試した程度でした。しかし昨年、古くなった3台の物理的なサーバを1台のハードウェアに統合するのにVMware ESXとローカルストレージ（SAN（ストレージ専用のネットワーク）ではなく、冗長性を持たせた複数のドライブをシャーシにおさめた単一のサーバを仮想マシンのストレージとしたものです）を利用したディレクトリサービス統合プロジェクトがありました。その結果は見事な物でした。なんといってもラックスペースがかなり空き、古いハードウェアは撤去され、接続するケーブルの数はずっと少なくなったのですから！VMwareがこの統合プロジェクトで効果を発揮したことで、仮想マシンの利用が有効であることが小規模なスケールで証明されました。
今回のプロジェクト
ディレクトリサービス統合プロジェクトから離れて息継ぎをした私は、関心を次の段階に向けました。それが開発にもVMwareを導入することでした。
開発環境について取り組むことにはデータセンタで経験する課題とは違った課題があります。まず、そこにいる人たちは当然のことながら非常に技術に精通していて、そのような中で何かうまくいかないことがあれば、本当にプロジェクトがダメになるということです。さらに、変更はいつでも起き、プロジェクトを進めるにはその変更要求を実現しないといけません。私の作業の多くはディベロッパとそのコンピュータ関係の要求をサポートすることで、それにはラボのメンテナンスやハードウェアやLANの整備なども含まれていました。このラボは管理するのが本当に厄介なところでした。ハードウェアはPCクラスのものもあれば、完全な冗長性を備えたワークステーションやサーバまでありました。メモリ容量や処理能力、ディスク容量はマシンごとに異なり、散発する電力変動からそれらを守るUPSも割拠していました。言うまでもないことですが、ハードウェアの違い、ドライバのバージョンの相違、BIOSのアップデート、アプリケーションの互換性サポートといったことは、環境の一貫性・信頼性・管理のしやすさの維持を難しくします。またアプリケーションのテストでは、それをおこなう度に新しいマシンを用意するか（当然他のマシンとは同じスペックになりえません）、既存ハードウェアを再度用意し直して新しいOS用にBIOS のアップデートなどの面倒な作業をおこなわないといけませんでした。
開発拠点のインフラを各サーバ機器をベースにしたものからVMware InfrastructureとSANを使ったものにデザインしなおすのには思考の転換が必要となります。この新しいアーキテクチャへの移行は各サーバの一貫性というものを超越します。その拠点は需要に応じた利用と割り当て動的におこなえるリソースのるつぼとなり、そこでは冗長性の需要はリソースるつぼに適用するルールの集合として表されるようになります。そのようなデザインをおこなう時には、VMware InfrastructureのHigh Availability（HA）とDistributed Resource Schedule（DRS）は欠かせないものです。これらは別機能でも非現実的な機能でもなく、デザイン開始時から必要なものです。最初は何も分からないかもしれませんが、この機能についての学習曲線は急激に上向きます。どうやら仮想サーバ配備ではこの学習曲線を考慮することがあまりまだ根付いていないようです（私は近ごろBurton Groupの副社長兼データセンタ事業サービスディレクタのRichard Jones氏による「Advanced Virtualization Management（より高度な仮想化管理）」というタイトルのウェブキャストを見たのですが、そこでは高可用性を実現できている仮想サーバ環境は 10%にも満たないと指摘していました）。よくおこなわれる仮想化手法はまだサーバ統合に縛られています。1つの物理的サーバを1つの仮想サーバへ移行し、そして1台のホストマシンで複数の仮想サーバを稼働させているのです。確かにそれはデータセンターのスペースを節約することになるでしょうが、ある欠点も生みます。それは、もしホストマシンがダウンすれば全ての仮想サーバも消えてしまうということです。
VMwareの配備
今回の作業は3つのVMwareホストサーバ（ESX 3.5がプリインストール済み）とSAN、そしてファイバチャネル（SANで使われるプロトコル）スイッチが揃った時点から始まりました。特別な機器設定はなく、UPSにはAPC社のSymmetraを使いました。この時に私は、ファイバケーブルはCAT 5ケーブルよりずっとデリケートにを扱わないといけないということを学びましたね！機器の設定が終わり動き出すと、今度は環境設定です。
このVMware環境の設定・管理をおこなうにはVirtual Infrastructure Client（VIC）を使います。ラボのブンブンとうるさい機械の横で作業するのでなく、静かで日射しの入るナイスな自分の部屋の自分のデスクトップからこのクライアントによって管理がおこなえるようになるのは格段の進歩です。真面目な話、あんなにたくさんあるファンの騒音への対抗手段としてこれに張り合えるのは最高の耳栓と耳当てぐらいです。VICは非常に直感的なツールで、クラスタ、テンプレート、サーバ、仮想スイッチの構成やHA、DRSのパラメータの設定を管理できます。まず、VICが私のマシンにインストールされていくつかのアイコンをデスクトップ上に置く権利が与えられました。そして私はアプリケーションなどでリソースを分割するのでなく、3つのVMwareホストを単一のクラスタにして全てのリソースをルートプールへと集めるように選択しました。このインフラではこんな変更がいとも簡単にできてしまうことはショッキングかつ面白いことでした。これは素晴らしいことです。自分の環境にとって最善の設定は何か、というのを考えられるいくつもの選択肢の中から選ぶのに試行錯誤することから解放されるのですから。新しい環境ができたら、次は実際に物理サーバから仮想サーバへの移行をおこなう番です。そのために、私はVMware Converter（P2V）とサーバテンプレートを組み合わせて既存環境を再作成することにしました。当然ながら、仮想環境への移行に先立っては各サーバのフルバックアップをおこないました。これは最低1回はすべきです。移行の途中では何度か、特にWindows 2000 Serverの入ったデバイスにConverterを使おうとした時に問題がありましたが、どれも乗り切ることができました。場合によっては新しい仮想マシンを一から構築してデータやアプリケーションをコピーしないといけないこともありましたが、これにはサーバのクリーンアップができるという利点がありました。
ここまでの状態
下の図はVMwareを導入する前のラボの構成です。お分かりのように、ケーブル管理は大変で、ワークステーションの冗長性はほとんど欠けていました。
VMwareを導入して物理サーバから仮想サーバへの変換（P2V）や物理サーバをリプレースした仮想マシンの構築をおこなった後の構成が次の図です。:
これでラボは前よりずっと冗長性とHAによる高可用性を備えるようになり、各サーバでハードウェアを持っていた時のように物理的制限に各サーバのリソースが縛られることもなくなりました。3つのホストサーバのリソースを集めたことで仮想マシンは動的に更新可能、かつ必要なだけのリソースが提供されるようになりました。さらに、私も新調した4台の液晶ディスプレイを見ながらリモートクライアントで仮想マシンにアクセスできるようになりました。ラボの機器専有面積はトータルで85%削減でき、また室温もずっと涼しくなり、エアコンがなくてもいいくらいです。
可用性を試す
私たちのクラスタは高可用であるように構成されましたが、謳い文句通りに動作するのかを見ることにしました。
この時点での私たちの環境は3つのホスト（A、B、C）とその上にある12の仮想マシンから成っていました。VMotionを使って11の仮想マシンをBと Cに移し、1つのWindows 2003 ServerだけをAに残しました。そして通常は非常にまずいと考えられることをやってみました。ホストAから電源コード（予備のものも）を引き抜いたのです。期待通りなら、VMotion HAはホストAが落ちたことを検知して、AにあったVMを自動的に他のホストとリソースを使って再起動するはずです。果たしてその通りになったでしょうか？結果は、2分も経たないうちにAにあったVMがBでログインできる状態になりました。次に、同じテストをWindows 2000 Serverにしておこなってみましたが、やはり2分以内に別のホストで自動的に再起動が完了しました。さらなるテストとして、同じようにA上の複数の仮想マシンを別のホストで再起動させた後、ホストAの電源を入れ、クラスタの冗長性を復帰させたところ、VMotionは元々Aにあった仮想マシンをAに戻して実行させました。これらのテストから私たちの環境においてVMwareを使用する効果は計り知れない程だと確信しました。
メリット
ラボはVMwareを使って数ヶ月経ちますが、その恩恵は明らかになりつつあります。その中でも特に目立つのは次の事柄です。:
- ラボの管理がずっと容易になりました。ばらばらの13のデバイスから3つの同一デバイスに移行したことでずっとシンプルで簡単になったのです。これに合わせてKVM、液晶ディスプレイ、小さなUPS、全てのケーブルがなくなったことでラボのスペースが85%も節約できました。
- 柔軟性が大幅に向上しました。たとえば、あるデータベース問い合わせに最適なリソース量（RAMとCPUの両方）を決めるために、ある仮想マシンへのリソース割り当て量を調整して、レスポンスが低下するポイントを特定するまで繰り返しテストすることができました。これをハードウェアでやることになっていたら、ハードウェアの費用がかさむだけでなく時間もかかり悲惨なことになっていたでしょう。
- ネットワークのスループットが向上しました。以前は各デバイスのネットワークスループットは、それぞれが備えるNICの数（ほとんどは1つのみ）に依存していました。現在では各ESXホストは複数ポートを持つ複数のNICを備え、それらが協調することで利用可能な帯域を倍増させ、かつNICの故障に対するネットワークの耐性も生んでいます。このように構成されていることは、バックアップにかかる時間の削減にもつながっています。
- HA、DRS、VMotionを使うことで冗長性と可動時間が大幅に向上しました。
現状
NYCE の開発環境は現在VMwareに移行しましたが、その成果に私はこれ以上なく満足しています。この開発環境は柔軟というレベルをはるかに超えています。サーバの配備は数週間でなく数分で終わり、リソースの再配分はいつでもできます。HA・DRSと一緒にVMotionを使うことで可動時間と信頼レベルは向上し、365日24時間利用可能な環境を維持し続けています。ビジネス面でも嬉しいことがあります。オンサイトのメンテナンスにかかる費用を1ダースのマシンに対する分から、たった3つに対する分へ減らすことができたのです。全体的に言って、VMwareへの移行は非常に有益なもので、社内の他の環境でもVMwareが利用されるのを待ち望んでいます。
著者について
Mak King氏はNYCE Payments Network, LLCのビジネス・システム・エンジニアです。みなさんからのコメントをお待ちしています。直接のコンタクト先はakamak at gmail dot comです。
免責
この記事にある情報、見解、意見は全て著者のものであり、NYCE Payments Network, LLCの研究、見解、意見を述べたものではありません。NYCE Payments Network, LLCはこの記事のいかなる情報、見解、意見についても責はなく、また説明責任も負いかねます。ここにある情報、見解、意見についての全責任は著者の負うところです。