システム構成は2次元から3次元へ進化―クラウドの「中身」を知る—Part3

クラウド構築の勘所

本パートでは、仮想化技術を活用してIT資源をクラウド化する具体的なテクニックを、プライベートクラウドの構築を例に解説する。クラウドの基本構成を知るにも役立つはずだ。

クラウドの利点は分かるが、外部のデータセンターに自社のデータを預けるのはどうも不安だ─。そう話すユーザー企業は多い。

そこで注目を集めているのが、ユーザー企業が自社のデータセンターでクラウド環境を構築・運用する「プライベートクラウド」である。本パートでは、プライベートクラウドの構築法を5つのステップに分けて述べていく。世に数多く登場してきたクラウドサービスの実体を理解する上でも参考になるはずだ。

Step01
仮想化ソフトをインストールする

図3-1　VMを生成するラック構成

社内でのクラウド環境の構築は、VM（Virtual Machine：仮想マシン）を稼働させる環境を準備することから始まる。そのための最低限のシステム構成は、複数のPCサーバーとストレージ、L2スイッチとFC（Fibre Channel：ファイバチャネル）スイッチである。今回は、9台のPCサーバーを使用する場合を想定する。仮想化ソフトとしてVMwareを使うことにする（図3-1）。

それぞれのPCサーバーには、4コアのx86 CPUを2個と、32ギガバイト以上のメモリーを搭載しておく。ネットワークカードは1ギガビット対応でもよいが、将来の拡張性を考えれば10ギガビット対応のものを用意したい。さらに、SAN（Storage Area Network：ストレージエリアネットワーク）ストレージにアクセスするためのFCボードを搭載する。こちらは、4ギガビット/秒のデータ転送速度を推奨したい。

SANストレージには、15個のハードディスク装置（HDD）を搭載できるとし、6＋1個のHDDからなるディスクアレイを、RAID 5で2つ組む。残った1個のHDDはスペアとする。1つのRAIDを1つのLU（Logical Unit：論理装置）とする。

HDDの回転数は、できれば1万5000回転/分を推奨したい。というのも、クラウドでは1台のPCサーバーで10個以上のVMを走らせたい。その場合、1つのストレージに対して複数のVMが同時にデータの読み取りや書き込みを行うといったことが起きる。その時に、通常のPCで使っている7200回転/分のHDDだと、あるVMがストレージにアクセスしている間、別のVMは待たされることになり、クラウド全体の性能劣化を招くからである。

さて、ハードの準備ができたところで、VMware ESX（以下ESX）をそれぞれのPCサーバーの内蔵ハードディスクにインストールする。ESXはハイパーバイザと呼ぶプログラムで、PCサーバー上でネイティブで動く。つまり、ESXはWindowsやLinuxといったOSの上で動くアプリケーションではなく、ハード上で直接動く仮想化専用のOSと言うことができる。

Step02
VMを作成して管理サーバーに登録する

9台のPCサーバーにESXをインストールしたら、それらをVMwareの管理サーバーであるVMware vCenter Server（以下vCenter）に登録する。今回は、9台のESXを1つのグループ（クラスタと呼ぶ）として登録し、先ほど構成したSANストレージの2つのLUを割り当てる。これにより、9台のESXが2つのLUを共有することになる。

次に、各VMにCPUを何コアずつ割り当てるのか、メモリーを何ギガバイトずつ割り当てるのかを決定し、vCenterでVMを作成する。

ただしこのままでは、あるESXでハード障害があると、そのESX上で稼働していたVMは全滅してしまうことになる。そこで、同じクラスタにある9台のESXでHA（High Availability：高可用性）構成を指定し、さらにLU内のリソースを共有するようvCenterの画面で設定する。これにより、ハード障害が発生したESX上で動いていたVMは、同一クラスタ内のほかのESXで動き続けられるようになる。

Step03
各種管理サーバーやネットワーク機器を設置

vCenterでVMを作成した。ESX間でリソースを共有する設定も実施した。これらだけではまだ、クラウド環境を安心して運用できない。vCenter以外に、各種の管理サーバーを導入すべきである。

まず、それぞれのESXや管理サーバーのIPアドレスを管理するDNS（Domain Name System：ドメインネームサービス）サーバーや、各サーバーの時刻を同期させるNTP（Network Time Protocol ：ネットワークタイムプロトコル）サーバーが必要だ。このほか、個々のハードを監視するハード監視用サーバーや、ネットワークの稼働状況やQoSを監視するサーバー、ESXやvCenterなどのプロセスの稼働状況を監視するサーバー、バックアップサーバーも用意しなければならない。

一方、ESX上で走るVMに社内やグループ企業、インターネットからアクセスできるようにするには、外部接続の仕組みが必要である。具体的には、社内ネットワーク、グループネットワーク、インターネットそれぞれにL3スイッチを用意する。もちろん、L3スイッチの前にファイアウォールやロードバランサを置くこともある。

こうした管理サーバーを追加した結果、プライベートクラウド環境は39ページ図3-2のような構成になる。ここでは、9台のESXを1つのクラスタとして、4つのクラスタで構成するクラウド環境を例にした。1つのESXで16台のVMを走らせるとすれば、全体でのVMの数は、

となる。

図3-2　クラウドの全体構成（クリックで画像を拡大）

Step04
クラウド基盤となる「ホスト空間」を構築する

クラウド環境では、ESXやvCenterなどの管理サーバー、SANストレージ、L2スイッチ、L3スイッチといった個々のコンポーネントにIPアドレスを割り振る必要がある。具体的には、VLAN（Virtual LAN：仮想LAN）機能を使って社内アドレスとは異なるアドレス体系を導入し、コンポーネントの種別ごとに172.16.10.0/24から172.16.14.0/24のIPアドレスを振る（表3-1）。

これらのアドレスは、クラウドの基盤を構成することから、ここでは「ホスト空間」と呼ぶことにする。ホスト空間は、プライベートクラウドの運用管理者がアクセスするネットワーク空間であり、クラウド上のVMを利用する利用者はアクセスできない。

ここで、「プライベートクラウドは自社に設置するのだから、社内で使っているアドレスを使えばよいではないか」という疑問を持つ読者がいるかもしれない。なぜ、わざわざ別のネットワークアドレスを使う必要があるのだろうか。

その理由は、ハード障害などにより、あるESXで実行中のVMを別のESXに移動させるケースを想像すれば理解できる。ホスト空間を社内ネットワークと同一にすると、VMがESX間を移動するたびに、社内ネットワークに大量のデータが流れることになるからだ。実行中のVMを移動させる際、ネットワークに一時的に流れるVMのイメージの容量は、1ギガバイトにもなる。

もちろん、L3スイッチを使ってホスト空間のセグメントを分けておけば、VMの移動による大量のデータ転送が社内ネットワーク全体に影響を及ぼすことはない。しかし、後々の運用を考えると、ホスト空間を独立したネットワークにすることを奨めたい。障害が発生した際に、原因を特定しやすくなるからだ。このほか、ホスト空間だけに新たな監視機能を導入する、といったことも可能になる。

Step05
利用者別の「ゲスト空間」を構築する

利用者のVMには、ホスト空間からは独立したIPアドレスを割り当てる。このVMに割り当てるネットワークを「ゲスト空間」と呼ぶことにする。

利用者がクラウド環境を社内ネットワークから使うのであれば、個々のVMには社内ネットワークのIPアドレスが割り当てられる。この場合、ゲスト空間は社内ネットワークの一部のセグメントを構成することになる。

一方、利用者が社外からVMにアクセスする場合、そのVMには社外からアクセスできるIPアドレスを割り当てる。一般的には、グローバルアドレスを割り当てることになる。

図3-3　ホスト空間上に複数の独立したゲスト空間

このように、クラウド環境上のゲスト空間においては、誰がどこからアクセスするかによって、VMのIPアドレスが異なることに注意したい。クラウド環境には、管理用の1つのホスト空間と、利用者ごとの複数のゲスト空間が存在し、システム構成はゲスト空間の奥行きがある3次元構成になる（図3-3）。

企業向けクラウドを運用してきた経験から我々が得た知見に基づき、プライベートクラウドをいかに実現するかを概説した。みなさんがプライベートクラウドをスムースに構築し、運用する一助となれば幸いである。