1

Linux+Xenによるサーバ仮想化 構築事例のご紹介

日本仮想化技術株式会社 代表取締役社長兼CEO 宮原 徹

miyahara@VirtualTech.jp

2

日本仮想化技術株式会社 概要

社名：日本仮想化技術株式会社 英語名：VirtualTech Japan Inc.

略称：日本仮想化技術／VTJ

設立：2006年12月

資本金：14,250,000円

本社：東京都渋谷区渋谷1-1-10

取締役：代表取締役社長兼CEO 宮原 徹

取締役CTO 伊藤 宏通

スタッフ：8名（うち、5.5名が仮想化技術専門エンジニアです）

URL：http://VirtualTech.jp/

仮想化技術に関する研究および開発 ‒  仮想化技術に関する各種調査 ‒  仮想化技術に関連したソフトウェアの開発 ‒  仮想化技術を導入したシステムの構築

日本初の独立系 仮想化技術専業会社（当社調べ）

2

会社沿革

•  2001年1月 株式会社びぎねっと 設立 ‒ 代表取締役社長に宮原 徹が就任 ‒  Linux/OSS技術者教育を中心に事業を展開

•  2006年1月 （株）びぎねっと 年間新規事業開発テーマを「仮想化技術」に設定 ‒ 日本で初めてXen上でWindowsの動作に成功

•  2006年12月 新規事業会社として「日本仮想化技術株式会社」を設立 ‒  （株）びぎねっとの兄弟会社として設立 ‒ 代表取締役社長に宮原 徹、CTOに伊藤 宏通が就任

3

4

導入

仮想化環境構築をトータルサポート

設計 •  設計

–  サーバ、ストレージからネットワークまで –  キャパシティプランニング（ベンチマーク）

•  導入 –  仮想化ソリューションパッケージの提供 –  運用管理システムの提供 –  仮想化統合（P2Vレガシーマイグレーション）

•  運用保守 –  エンジニア教育 –  技術サポートの提供 ‒  Xenソースコードレベルサポート

運用保守

3

要するにこういう会社です

•  仮想化技術に特化した会社です •  仮想化技術に関する経験が豊富です •  仮想化関連の製品／ソリューションを成熟させます

•  仮想化技術が今後ITの重要なコアインフラ技術になると確信しています

•  仮想化技術をしっかりとサポートします

5

『仮想化技術Xen−概念と内部構造』

•  日本仮想化技術株式会社 技術陣による監訳

•  Xenの内部構造について唯一の詳細な解説書 – 設計に役立つ – 構築に役立つ –  トラブルシューティングに役立つ

•  2008年8月20日発売 •  4800円＋税

6

4

本日のアジェンダ

•  サーバ仮想化のメリット •  仮想化ソフトウェア選択のポイント •  事例のご紹介

– 設計のポイント – 構築・運用のポイント

•  Hinemos仮想化対応拡張について

7

サーバ仮想化のメリット

5

9

サーバ仮想化のメリット

•  サーバ集約が可能 – 省電力・省スペース・H/W管理コストの削減 –  リソースの有効利用

•  標準化と可搬性の確保 – 運用管理コストの削減 – 迅速なプロビジョニング –  HA・DRにも柔軟に対応

•  低発熱・省電力 –  CO2排出量抑制の要請 –  iDCの冷房設備・ラックあたりの電力供給量の限界

10

サーバ集約が可能

•  複数マシンを1台に集約 – 省スペース – 省電力 – 管理コストの削減

•  リソース共有によるリソースの最適化 – 低利用率のCPUを統合 – 大容量メモリを複数システムで分割共有 – 各種I/Oを共有

仮想化のメリット①

6

11

標準化された マシン環境を提供

標準化されたマシン環境の提供

•  標準化された均一のマシン環境を提供 – 変化の早い物理マシン環境を、従来はOSがデバイスドライバ等で違いを吸収していた

– 仮想化により、物理マシンが変わってもOSには影響しない

物理マシン OS アプリ 仮想化

仮想化

仮想化のメリット②

12

可搬性の確保

•  仮想マシンは”OS＋アプリ”をコンテナ化 •  仮想化で仮想マシン実行環境が標準化

•  仮想マシンを簡単にコピー可能 –  素早いプロビジョニングを実現 –  実験開発環境から本番環境への「V2V」移行

•  仮想マシンをどこでも実行できる –  ライブマイグレーションの実現 –  HA構成も容易に構成可能

仮想化のメリット③

Apps OS

Apps OS

Apps OS

Apps OS

Apps OS

プロビジョニング

7

Host A

移動元 仮想マシン

Host B

共有ストレージ

システム ルートFS

移動先 仮想マシン

メモリ状態をコピー

ライブマイグレーションの仕組み

共有ストレージにはFC SANやiSCSI、 NFSが利用可能

仮想化のメリット③

デモ

14

8

Host A

移動元 仮想マシン

Host B

システム ルートFS

移動先 仮想マシン

ライブマイグレーション

LMデモ環境の仕組み

システム ルートFS NFS共有をマウント

/var/lib/xen/imagesに ルートFSがあるように 見えること

15

16 ※1Cタイプは仮想化せず、4Coreタイプは1Coreあたり2VMと仮定

発熱・消費電力比較表

Single Core Quad Core 比較値

スペース 1 1 100%

CPU 1 2 200%

コア 1 8 800%

システム数※ 1 16 1600%

消費電力(W) 270 630 233%

発熱量(kJ/h) 972 2,268 233%

消費電力/システム 270 39.375 15%

発熱量/システム 972 141.75 15%

電気代(月額/システム) ¥8,100 ¥1,181 ¥-6,919

仮想化のメリット④

9

17 ※『日経SYSTEMS』2007年6月号 検証ラボを参考

導入・ランニングコスト比較

•  ラック型1Uサイズ同士で比較 •  クアッドコア×2CPUで8コア → 16VMまで動作可能と仮定 – 負荷が低い処理の場合、さらにVM数を追加可能

•  電力消費は安定化電源のため負荷率に大きく影響されないと仮定

•  発熱量はマシン室の冷却等に影響するが、ここでは考慮に入れていない

•  電気代は1A(1000W)あたり月額3000円と仮定

仮想化のメリット④

仮想化ソフトウェア選択のポイント

10

VMware

•  VMware ESX Server – 実績が一番多い – Virtual Centerによる管理が（ほぼ）必須 – ライセンス・保守料が高額

•  VMware ESXi – 無償で利用可能 – サービスコンソール無し（ローカル処理不可） – お試し、スタンドアロン利用には耐えるか

19

Xen •  現在、最も注目されている

– 本格導入事例（カシオ計算機、パイオニア等） – 低コストソリューション

•  Windowsも稼働 – ゲストOS用ドライバの提供 – ライブマイグレーションのサポート（v3.1以降）

•  いくつかの課題も –  UNIX/Linux系の知識が必要 – ディストリビューションが多く、互換性の欠如 – 定番管理ツールが無い

20

11

Hyper-V

•  Windows Server 2008から正式サポート – 比較的低価格 – OS標準の強み？ – System Centerによる統合管理

•  これからの課題 – 技術的評価検証 – 実績作り

21

現時点での比較評価

実績 機能 運用管理 技術力 導入コスト ランニングコスト

VMware ◎ ○ ○ ○ △ △

Xen ○ ○ ？*1 ○*3 ◎ ○ Hyper-V △ ○ ？*2 ○ ○ ○

22

*1 標準ベースの運用管理作り込みの可否 *2 System Centerによる統合管理が未知数 *3 オープンソースによる開発

12

事例のご紹介

事例の概要

•  パイオニアシェアードサービス株式会社様 システム環境移行 –  Windows・Linux等でシステム構築済み –  VMwareの導入実績あり

•  システムリプレースのタイミングで仮想化環境を構築・移行 ‒  SLES10 SP2+Xenを採用

•  今後、Windowsサーバも含めた既存システムおよび新規システムも随時仮想化環境に移行予定

24

13

Xen選択の理由

•  オープンソースであること –  Linuxをはじめ、各種オープンソースソフトウェアを使用したシステム構築の実績あり

•  チャレンジ！ – VMware以外のソリューションへの取り組み – 中長期的に利用可能なインフラの整備

25

既存システムの状況

•  使用OS – SLES9・SLES10 – Red Hat Linux 8 – Red Hat Enterprise Linux ES 4 – Windows 2000 Server

•  主な使用ソフトウェア – Apache＋Tomcat – MySQL – PHP

26

14

設計のポイント

キャパシティプランニングと ハードウェアの選定

27

稼働状況の調査

•  特別なツールは不要 – OS標準の性能測定ツールで十分 – Windows：パフォーマンスモニタ – Linux：sarコマンド

•  ある程度以上の期間で取得すること – 最低でも1ヶ月の負荷変動を調査 – 時期により負荷が変わるのであればピークに合わせて取得できるのが望ましい

28

15

ボトルネックの解消

•  ハードウェアの問題 – CPUの不足（クロック数・CPU数） – メモリの不足 –  I/Oの不足（ディスク・NIC）

•  OS・アプリケーションの問題 – メモリ不足によるスワップアウトや速度低下 – チューニング不足（メール・DBなど）

29

ストレージ

•  今後の仮想化統合を考慮して、あらかじめパフォーマンスを十分に確保したい

•  XenではNFS・iSCSI・FC SANが使用可能

•  iSCSIとFC SANをベンチマークで比較 – FC SAN – FC SAN+iSCSI変換 – ソフトウェアiSCSI（SLES10）

30

16

ストレージの選定

•  最終的にFC SANを採用 – 高い性能 – ハードウェアのスナップショット機能 – レプリケーション（将来的に）

•  ストレージでのチャレンジ – パフォーマンスがあまり要求されない部分にはiSCSIを使用

– SLES10+iSCSI Enterprise TargetによるソフトウェアiSCSIターゲットを構築

31

多重化による冗長構成

•  VMの多重化とハードウェアの多重化を効果的に組み合わせる

•  VMの冗長化 – ライブマイグレーション経路の確保 – Heartbeat2を使用し、仮想マシンの監視による自動再起動

•  ハードウェアの多重化 – 構成の多重化と60%ルール – 障害発生時でも縮退運転可能

32

17

障害対策

•  設計段階で極力単一障害点を排除 – エンクロージャ：もう一方のエンクロージャへブレードを移行

– ブレード：HA監視で高速に再起動 – ネットワーク：NICのボンディングで多重化 – スイッチ：二重化 – FC：マルチパス接続（FCスイッチ使用）

•  ネットワーク対応パトライト –  「構成が地味なので・・」

33

ハードウェア構成の概略

34

FC SAN

Web LAN

DMZ iSCSI

エンクロージャ1 エンクロージャ2

障害発生時はもう一方へVM/ブレードを移行

18

60%ルール

35

VM1 VM2

VM3 VM4

VM5 VM6

VM2

VM3 VM4

VM5 VM6

VM1

正常稼働時

障害発生時 障害復旧移行

ブレードサーバの構成

•  全体で50VM程度動かせるように設計 •  CPU：8コア（4コア×2プロセッサ） •  メモリ：14GB ‒  2GB/VM ‒  6VM/ブレード（CPUコアをフル活用可能）

•  ブレードサーバ：11台＋2台（iSCSI用） ‒  6VM×11＝66VM ‒  「60%ルール」適用後でも約40VM

36

19

CPU使用率の計算方法

•  CPUクロック数の世代間性能差に留意 – CPUの性能指標であるクロック数は製品の世代によって性能が異なる

– 実質的なクロック対性能は大きく変わっていないので、クロック数比で計算してもよい？

37

CPU コア数 MHz 実質MHz SPECint2000 MHz/SPECint2000

Xeon 3.0GHz(推定) 1 3000 3000 1,429 2.10

Xeon 3.4GHz 1 3400 3400 1,617 2.10

Xeon 3.6GHz 1 3600 3600 1,718 2.10

Xeon 5110(1.6GHz) 2 1600 3200 1712 1.87

Xeon5160(3GHz) 2 3000 6000 3,025 1.98

SPECint2000による性能比較

CPU使用率の計算例

•  CPU使用率30%の物理マシンを、ほぼ同性能・同クロックの仮想マシンホストに移行 – CPU使用率60%まで可能なので、2VMまで収容可能

38

収容可能VM目安＝CPUコア数×2

20

ネットワーク設計

•  ネットワーク設計で考慮すべきポイント – セキュリティ（DMZとLANの分離） – 運用管理 – 冗長性

•  Xen＋VLANで柔軟な構成が可能 – サービスセグメントと管理セグメントを分割 – サービスセグメントをさらに目的別にセグメント分割

39

構築と運用

既存環境の移行と 仮想化環境運用のポイント

40

21

既存環境の移行

•  部分移行と全体移行の混在 –  Red Hat Linux 8→SLES10にアプリケーション移行 –  Red Hat Enterprise Linux ES4→疑似仮想化VMに変換

•  フェーズを前倒しして、Windows環境の移行も調査

–  Windows 2003はASRで移行可能 –  Windows 2000はツール利用を推奨(PlateSpinなど)

41

運用監視

•  仮想化環境の運用監視は「死活監視」と「負荷監視」が重要

•  NagiosからHinemosへ移行 •  Hinemosを独自に拡張し、仮想化環境に特化したシステム監視も可能 – 仮想マシンの追加・削除、起動・停止・ライブマイグレーション

– 仮想マシンの負荷状態の監視（CPU・メモリ・ネットワーク・ブロックデバイス）

–  リモートコンソール 42

22

Hinemosの仮想化対応

•  仮想マシンのリソース使用状況の取得 – 管理用Domain 0から情報取得 – CPU・メモリ・ネットワーク

•  仮想マシンの管理 – 起動・停止・ライブマイグレーション – VNCによるリモートコンソール接続

43

Hinemos 性能監視画面

44

← CPU

← メモリ

← ネットワーク

← ディスク

23

Hinemos 性能監視設定画面

45

バックアップ

•  仮想マシンの特性を活かし、仮想マシンを稼働させつつシステム全体をバックアップ

•  ストレージの機能を活用した手順 1.  FC SANのハードウェアスナップショット 2.  スナップショットをバックアップサーバでマウント

3.  中身をバックアップソフトウェアでテープライブラリにバックアップ

46

24

今後の展開

•  Hinemos 協業パートナーとしての展開 – Hinemosを使用したシステム全体のコンサルティング＋仮想化

– Hinemosの教育・販売・サポート

•  仮想化対応について – VMware対応 – Hyper-V対応

47

案件絶賛募集中

48

お問い合わせ先

「仮想化環境を構築したいが、どこに相談すればいいの？」

まずは我々にご相談ください

日本仮想化技術株式会社

http://VirtualTech.jp/ sales@VirtualTech.jp 050-7571-0584