第1回は、『仮想化技術のメリットとデメリット』です。
是非ご一読下さい。

第1回 仮想化技術のメリットとデメリット
http://thinkit.co.jp/story/2011/02/01/1970

構成

評価システムは以下のような構成です。

1Uサーバ ハードウェア仕様

ストレージ ハードウェア仕様（Linux SCST softwareターゲット）
1号機

2号機

構成解説

今回の評価では、BR1020を搭載した1UサーバからBR8000を経由してFibre Channel(以下FC)ストレージ装置にアクセスを行い、その性能を計測しました。
ここで問題となったのが弊社に常設されているFCストレージシステムでは、10GbEのFCoEが持つと予想される帯域幅やIO性能を十分に発揮させることができないということでした。
通常、この手の試験では、この問題を回避するため、SANBlaze Technology社のターゲットエミュレーションシステムを利用することで、超高速なストレージ装置をエミュレートして性能測定を行います。ですが、今回はLinux SCST(Software SCSI target)のNULLIO modeを利用することで、この問題を回避しました。

測定方法

測定は、1UサーバにOSとしてMicrosoft Windows Server 2008 R2 Enterpriseを導入後、ベンチマークツールであるIOmeter(2008-06-22-rc2)を利用して行いました。
帯域幅の測定は、1MB単位でシーケンシャルなアクセスを行うワーカー（ディスクへのIOを実際に行うIOmeterのプロセス）をターゲットごとに動作させて行いました。
※ターゲットは、各ストレージハードウェアのFCポート毎に作成したため４つです。よってワーカーの数も4つです。各ワーカーのQueue Depthは1に設定

IO性能（IOPS）の測定は、4KB単位でランダムなアクセスを行うワーカーを1Uサーバに搭載されているコア数である8つ動作させて行いました。
※各ワーカーのQueue Depthは8に設定

測定結果

以下の測定結果は、BR1020の1ポートだけを利用した場合の値です。
（2ポートの場合は、ターゲット側の性能不足で正しい計測値が得られませんでした）

測定結果解説

帯域幅の測定結果は、10GbEの持つ帯域幅をほぼ使い切る性能があることを示しています。またCPU負荷も非常に低く抑えられています。
IO性能（IOPS）の測定結果は、アクセス単位が4KBなことを考えると、10GbEの持つ帯域幅が律速となる最大IOPS性能を持っていることを示しています。
CPU負荷も同時に計測を行った他社の10GbE NICと比較すると半分近くに抑えられておりDCB及びFCoE処理をすべてカード側で行うBR1020の優位性が確認できました。

まとめ

10GbE 1ポート及び4Gb FC 4ポートのみでのテストでしたが、Brocade8000がDCB(CEE)及びFCoEに対応したスイッチとして高い性能を持っていることが伺える測定結果が得られました。
また、CNAであるBrocade 1020がDCB及びFCoE処理をホスト側にほとんど負荷を掛けずに行え、10GbEの持つ帯域をフルに活用できる性能を持っていることが確認できました。

IIJさんは、あえてコンテナ型データセンターとは呼ばずに次世代モジュール型エコ・データセンターと呼んでいます、理由は後で出てきます。

今回見学させて頂いた施設は、保安上の理由から場所は原則非公開です。（中部地区某所ってところまでは公開してOK）

現在建設中の本番データセンターの場所は、寒からず・暑からずの中国地方だそうです。（ネットで検索すると自治体名まで出てきます）

施設に到着して、実際に見学する前に、レクチャーを受けました。内容を抜粋すると以下のような感じです。

なぜIIJはコンテナ型データセンターをつくるのか？

• 従来のデータセンターは、建築コストが高い
• 従来のデータセンターは、一度にまとめて広いフロアを建設しないといけない
• 従来のデータセンターは、建築に長い時間が必要なため、需要発生から供給までのリードタイムが長い
• リードタイムが長いために、大量に在庫（空きラック）を抱えるリスクを負う必要がある
• これらの問題を解決するためにコンテナ型データセンターを選択して検証して実際に建設することにした。

IIJ 次世代モジュール型エコ・データセンターの特徴

• 外気導入型空冷で通年PUE 1.2
• 日本の事情に合わせた設計
• 屋根無し（コンテナを屋外に設置）
• コモディティサーバを利用（コンテナ型専用タイプは利用しない予定）
• N+１タイプの空調装置（コンテナごとに1台と予備1台）

実証実験の概要

• 実証実験のパートナーと実施
• コンテナ製造　NLMエカル（日本軽金属の子会社でコンテナ製造が本業）
• 電気空調設備　東芝
• 防災消火設備　能美防災
• ラック分電盤電流測定器　河村電器産業
• IT機器　国際産業技術（OTTOさん）
• 外気冷却方式の実証実験が主目的である
• ASHRAE（アメリカ暖房冷凍空調学会）の温湿度条件ASHRAE class1&2 recommended level(2008 Version)に収める制御を行う

空調システムの動作モード概要

• 中間期　外気運転モード（外気をそのままコールドエリアに供給、ホットエリアの排熱は全て排気）
• 冬期　　混合運転モード（冷たく乾燥しすぎの外気をホットエリアの排気と混合して、適切な温湿度にしてコールドエリアに供給）
• 夏期　　循環運転モード（外気は利用せず、冷却機を稼動して運転）

参加者にレクチャーするIIJ堂前さん

レクチャー中に行われた質疑応答の内容を抜粋すると以下の通りです。

コンテナ型データセンターの何が１番のメリット？

• リードタイムの短縮

コンテナのサイズは？

• 幅3m、高さ3m 、奥行き 8m で所謂ISO規格コンテナではない
• ISO規格コンテナでは、幅が狭まい（幅は2.438m、高さは2種類2.591mと2.896m長さも2種類6.096mと12.192m）
• ISO規格コンテナではないので、モジュール型と呼んでいる
• 日本の道路交通法上、輸送に許可を必要とするサイズなので、将来的には許可が不要なサイズに変更する予定

コモディティサーバを利用する理由は？

• 専用設計のサーバを利用するとリードタイム短縮効果が薄れる可能性がある
• 大きな仕様変更には、サーバメーカーは消極的
• 通常のサーバから冷却ファンを抜いた仕様などは、PUE値の比較では不利になるが利用を考えている

PUE値が不利になる理由は？

• PUEは、データセンター全体の消費電力をIT機器の消費電力で割った値
• サーバから冷却ファンを取り外すと、そのかわりに空調装置側の負荷（電力）が増えることになる
• 冷却ファンの電力がIT機器の消費電力から減って、空調装置側の電力が全体の消費電力に追加されることになり、PUEの値は大きく（悪く）なる
• 一般的に、サーバの冷却ファンよりも空調装置の大型ファンの効率がよいので、全体の消費電力を押さえることができるのに、PUEの値は悪くなる
• PUEの問題点は、さまざま指摘されているが、他の指標（DCiE・DPPE・etc）にも問題がないわけではなく、またPUE程認知されていない。

他の指標の問題点ってなに？

• 自然エネルギーや再生可能エネルギーをつかっても評価されない

温度及び湿度に下限がある理由は？

• 温度の下限は、モータ等に利用されているオイルの粘性など
• 湿度の下限は、静電気の発生を抑えることが理由
• 温度の上限は、あらゆる部品の故障率や寿命に関連
• 湿度の上限は、結露及び腐食

サーバのキッティングは、どこで行うの？

• 実証実験では、コンテナを設置後に行った
• 本番では、運送前にキッティングを行う予定

コンテナに輸送及び地震に関連する振動対策はあるのか？

• Oracle（元Sun）のコンテナ型にあるコイルスプリングのような対策はしていない
• 輸送時は、エアサス車を利用することで対応可能だと考えている
• 地震対策としては、震度7レベルの耐震設計を行っている

屋根無しで大丈夫なのか？

• 建築基準法などの法規に関連する問題は、データセンター特区でクリアできる予定(2010/8/10 23:22修正）国土交通省からコンテナ型データセンターは建築物扱いされないとの検討結果が発表されたのでクリアしている（参考 構造改革特別区域推進本部 資料1 PDF・検討要請に対する各府省庁からの回答　国土交通省 PDF 6ページ）
• 実証実験の設備は、４号建築物の特例でクリアしている（コンテナの製造を担当しているNLMエカルには、携帯電話基地局などでの実績があり、また1級建築士が在籍している）
• 屋根有りを選ぶ海外事例もあるので、情報収集は続けていく予定

障害対応は？

• 冷却機の障害には、N+1構成で対応（障害時には各ユニット間の接続部分にあるダンパー（空気弁）を開放して全体で支えるモードに移行する）
• 電源装置の障害には、自家発電機などで対応
• 人が作業中に空調が故障するケースもテストしたが、無事生還しております。
• Googleなどの行っているデータセンターレベルでの切り替え等は、今後の課題

サーバ故障時の対応方法は？

• 定期メンテナンス時にまとめて修理交換を行う
• 故障したサーバを完全にほっておく手法はとらない予定

なぜ、中部地方を実証実験の場所に選んだの？

• 実証実験の場所と立地条件とは特に関連はない
• この実証実験で得られた情報と日本全国の気象情報を元に、大体の指標を得ることはできる

コンテナ内での負荷の偏りには対応しているのか？

• 負荷が偏った状態でのテストを行ったが、熱の偏り等は、問題ないレベルで収束することを確認済

発熱量の大きいCPUやメモリと比較的少ないHDDを別のコンテナに収容することは検討しているか？

• コンテナごとに空調を調整できるので、メリットはあるかもしれない
• Flash SSDが主流になれば、メリットはなくなるかもしれない

ネットワーク機器への対応は？

• エアフローの観点から、前後方向での吸排気に対応している機器を使いたい
• 今回、横方向の製品を一部使っているが、たぶんちゃんと冷えていない筈

海外の事例にある、コンテナの2階建ては？

• やらない予定
• 地震対策や、下になるコンテナの強度アップにコストが必要
• コストに釣り合う効果が専有面積を減らすことにはない

枠を作ってコンテナを収める工法は？

• 一般論として建設費が高くなる
• 土地代が安い場所を選択しているので、採用はないと思われる

直流電源の検証予定は？

• 直流給電の規格が落ち着いたら考えます。

防災対策は？

• 地震対策は、震度7クラスに耐える設計を行っている
• 火災対策は、本番環境では窒素消火設備を利用予定

防犯対策は？

• 用地の周囲に壁を作る予定
• 無人運用ではなく、管理棟もあり警備員等も配置する予定

参加者の質問に答えるIIJ久保さん

質疑応答が一段落ついたところで、実際に実証実験中の設備を見学させていただきました。

実物を見ながらの解説の内容を抜粋すると以下のような感じです。

• この形になるまでに、幾つか変更を行っている
• 空調用コンプレッサーの変更
• 排気側ファンを外した
• 加湿用の給水パイプはこれ（写真参考）
• ITモジュールと空調モジュールは、フレシキブルな構造で接続(地震対策)
• LED照明を利用
• 扉は２重で前室あり（外部の庇は、小さすぎた・・・）
• 前室に配電盤を設置
• 実証実験で利用しているサーバは、熱源として利用
• OpenSSLのベンチマークコマンドで熱量を制御
• 温度湿度センサー（ストロベリー・リナックス製）を計測用に設置
• 今日は、見学なので6割程度の負荷で運用
• 最大負荷だと、凄い風量（最大27000立方メートル毎分）になる（6割でも凄い風量でした）
• 普通の煙センサーは、天井設置しますが、風量が凄すぎて天井では反応しないため、排気側ダクト前に設置している。しかも超高感度煙センサーの中でもより感度の高い製品を採用している
• 空調制御用の温湿度センサー、特に温度センサーは応答時間が極めて短いものを利用している

モジュール全景

ITモジュール

空調モジュール

フレシキブルなダクトの継ぎ手

空調モジュールを解説するIIJ堂前さん

加湿用水供給システムを解説するIIJ堂前さん

前室にある配電盤

配電盤内　電流測定用コイルがいっぱい

空調制御用温湿度センサー

超高感度煙センサー

煙センサーへの空気取り入れパイプ

コールドエリア側全景

ホットエリア側全景

温湿度センサーと熱源サーバ群

見学中に行われた質疑応答の内容を抜粋すると以下の通りです。

塗装しないの？

• 本番では、遮熱塗装を行うかを検討中（費用対効果を検討）
• 遮熱板は検討してみます（直射日光の当たる信号機等の制御ボックスなどにある筐体からは浮いた板）

配電盤に繋がったパイプは何？

• 当初の予想より配電盤からの熱が大きく前室が高温になったために、コールドエリア（通路ではないのでコールドアイルとは呼ばないことにしたそうです）から冷気を導入している

実証実験の費用は分担？

• IIJが負担している（部分が大きい？　聞き逃しました）
• パートナー各社にも、いろいろと便宜をはかってもらっている

感想

IIJさんが、先行する企業からのノウハウ導入だけではなく、自社のコンテナ型データセンターを建造する為に、ここまで努力している点には、素直に敬服しました。

質問にも、積極的に回答いただけて大変感謝しております。まだ、幾つか質問したい項目（降雪落雷対策・高温度運用の可能性・ネットワーク遅延etc）があったのですがそれは、別の機会にしたいと思います。

我々が検証した結果についてお話しますので、コストパフォーマンスの高いストレージをお探しの方は是非ご参加下さい。

申し込みページはこちら

　用意するものは次の2台のマシン（もしくは、1台のマシンでハードディスクを差し替えても可）です。

• RHEL5のXen環境で作られたRHEL5の仮想マシン
  • 仮想マシンはlibvirtで管理されている必要があります
  • RHEL5がない場合はCentOS5でも問題ありません。また、本稿ではCentOS5を前提とします
• 移行先となるRHEL6(ベータ)のKVM環境
  • ブリッジ設定は適宜手動で行う必要があります

　まず、仮想マシンのデータを移行先のマシンに用意します。Xen環境で作成したVMをコピーすれば良いでしょう。ディスクイメージはコピー元と同じパスに配置します(/var/lib/xen/imagesを作成します)。設定ファイルは、libvirtのXML形式として出力したものを作業ディレクトリ（本稿では/rootとします）にコピーします。出力方法は次のとおりです。

# virsh dumpxml /etc/xen/＜VM名＞ > /root/＜VM名＞.xml

　次に、virt-v2vをインストールします。RHEL6標準のパッケージではバージョンが古く使い方がやや不明ですので、最新のソースをGitリポジトリからダウンロードしてビルドしたものを使用します。2010/5/14現在の最新は0.5.3です。ビルドの前に、あらかじめ次のパッケージをYumおよびCPANでインストールします。

# yum install git perl-libguestfs perl-XML-DOM-XPath perl-Sys-Virt
# cpan Locale::TextDomain

　インストールが済んだら、virt-v2vの最新ソースをダウンロードします。

# git clone git://git.fedorahosted.org/virt-v2v.git

　コンパイルおよびインストールの手順は次のとおりです。

# perl Build.pl
# ./Build
# ./Build install

　次に、変換したディスクイメージに組み込むカーネルとその関連パッケージ情報を記述した設定ファイルを作成します。これは、Xen用のカーネルから通常のカーネルに差し替える必要があるためです。すでに出来上がった設定ファイルを用意しましたので、こちらを使用（もしくは参考に）して下さい。

100514virt-v2v.conf.txt

　パッケージのバージョンは2010/5/10時点のものですが、virtioがサポートされているバージョン(RHEL5 Update3 or CentOS5.3以降)であれば問題ありませんので、必ずしも最新である必要はありません。この設定ファイルはタグ形式で記述します。以下にタグの説明を示します。

　パッケージ情報を記述し終えたら、それぞれのパッケージを指定したパスにダウンロードします(設定ファイル内にダウンロード用のwgetコマンドを埋め込んでおきました)。

　最後に、次の2点を行います。

• ストレージのプールをvirt-managerもしくはvirshコマンドで作成します。
• /var/lib/virt-v2vディレクトリを作成します。

　以上で準備は完了です。いよいよvirt-v2vコマンドを実行して、変換を行います。

# virt-v2v -i libvirtxml -op ＜ストレージのプール名＞ -f virt-v2v.conf ＜VM名＞.xml

　変換中はしばらく何もメッセージが表示されませんが、問題ありません。問題があった場合はメッセージが表示され、処理が中断されます。今回の例では最後に次のメッセージが表示されるかと思います。VMのデバイスにvirtioが利用されています、とのことです。

virt-v2v: ＜VM名＞ configured with virtiodrivers

　変換が完了したらlibvirtに登録するのですが、qemuの権限設定の問題でエラーとなってしまうため、対策を行います。/etc/libvirt/qemu.confを開いて、次の箇所のコメントアウトを戻します。保存したらlibvirtdを再起動して下さい。

# The user ID for QEMU processes run by the system instance
user = "root"   ←#をとる

# The group ID for QEMU processes run by the system instance
group = "root"   ←#をとる

　virshコマンドで変換したVMを登録します。登録が成功すると、即座にVMが起動するので、気を付けて下さい。virsh create(登録と同時に起動)もしくはvirsh define(登録のみ)で登録可能です(peo3さんご指摘ありがとうございました)。

# virsh create /etc/libvirt/qemu/＜VM名＞.xml
ドメイン＜VM名＞が/etc/libvirt/qemu/＜VM名＞.xmlから作成されました

　以上で変換作業は完了です。

期日は7月29日(水)、場所は飯田橋のホテルメトロポリタンエドモントです。私の講演は16時35分から。

テーマは現在検討中ですが、最近行ったベンチマーク結果などを踏まえて、あらためて最適な仮想化環境構築についてお話できればと考えております。

テーマ等決まりましたら、あらためてお知らせいたしますので、ご期待ください。