Linux+Xenによるサーバ仮想化構築事例セミナー
•
0 gefällt mir•1,642 views
講師：日本仮想化技術 宮原 日時：2008/8/25 概要： サーバ仮想化は、日々増え続けるサーバのランニングコスト増大を解決する手段として注目されています。その中でも「Xen」はオープンソースのサーバ仮想化ソフトウェアとしてLinuxとの親和性も高く、企業におけるサーバ集約の要として期待されています。 本講演では、LinuxとXenによる最新サーバ構築事例をふまえて、サーバ仮想化の設計、構築、運用での重要なポイントを解説します。
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (17)
Ähnlich wie Linux+Xenによるサーバ仮想化構築事例セミナー
Ähnlich wie Linux+Xenによるサーバ仮想化構築事例セミナー (20)
Mehr von VirtualTech Japan Inc.
Mehr von VirtualTech Japan Inc. (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (9)
Linux+Xenによるサーバ仮想化構築事例セミナー
- 1. 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. 2 会社沿革 • 2001年1月 株式会社びぎねっと 設立 ‒ 代表取締役社長に宮原 徹が就任 ‒ Linux/OSS技術者教育を中心に事業を展開 • 2006年1月 （株）びぎねっと 年間新規事業開発 テーマを「仮想化技術」に設定 ‒ 日本で初めてXen上でWindowsの動作に成功 • 2006年12月 新規事業会社として「日本仮想化技術 株式会社」を設立 ‒ （株）びぎねっとの兄弟会社として設立 ‒ 代表取締役社長に宮原 徹、CTOに伊藤 宏通が就任 3 4 導入 仮想化環境構築をトータルサポート 設計 • 設計 – サーバ、ストレージからネットワークまで – キャパシティプランニング（ベンチマーク） • 導入 – 仮想化ソリューションパッケージの提供 – 運用管理システムの提供 – 仮想化統合（P2Vレガシーマイグレーション） • 運用保守 – エンジニア教育 – 技術サポートの提供 ‒ Xenソースコードレベルサポート 運用保守
- 3. 3 要するにこういう会社です • 仮想化技術に特化した会社です • 仮想化技術に関する経験が豊富です • 仮想化関連の製品／ソリューションを成熟 させます • 仮想化技術が今後ITの重要なコアインフラ 技術になると確信しています • 仮想化技術をしっかりとサポートします 5 『仮想化技術Xen−概念と内部構造』 • 日本仮想化技術株式会社 技術陣による監訳 • Xenの内部構造について唯 一の詳細な解説書 – 設計に役立つ – 構築に役立つ – トラブルシューティングに役 立つ • 2008年8月20日発売 • 4800円＋税 6
- 4. 4 本日のアジェンダ • サーバ仮想化のメリット • 仮想化ソフトウェア選択のポイント • 事例のご紹介 – 設計のポイント – 構築・運用のポイント • Hinemos仮想化対応拡張について 7 サーバ仮想化のメリット
- 5. 5 9 サーバ仮想化のメリット • サーバ集約が可能 – 省電力・省スペース・H/W管理コストの削減 – リソースの有効利用 • 標準化と可搬性の確保 – 運用管理コストの削減 – 迅速なプロビジョニング – HA・DRにも柔軟に対応 • 低発熱・省電力 – CO2排出量抑制の要請 – iDCの冷房設備・ラックあたりの電力供給量の限界 10 サーバ集約が可能 • 複数マシンを1台に集約 – 省スペース – 省電力 – 管理コストの削減 • リソース共有によるリソースの最適化 – 低利用率のCPUを統合 – 大容量メモリを複数システムで分割共有 – 各種I/Oを共有 仮想化のメリット①
- 6. 6 11 標準化された マシン環境を提供 標準化されたマシン環境の提供 • 標準化された均一のマシン環境を提供 – 変化の早い物理マシン環境を、従来はOSが デバイスドライバ等で違いを吸収していた – 仮想化により、物理マシンが変わってもOSに は影響しない 物理マシン OS アプリ 仮想化 仮想化 仮想化のメリット② 12 可搬性の確保 • 仮想マシンは”OS＋アプリ”をコンテナ化 • 仮想化で仮想マシン実行環境が標準化 • 仮想マシンを簡単にコピー可能 – 素早いプロビジョニングを実現 – 実験開発環境から本番環境への「V2V」移行 • 仮想マシンをどこでも実行できる – ライブマイグレーションの実現 – HA構成も容易に構成可能 仮想化のメリット③ Apps OS Apps OS Apps OS Apps OS Apps OS プロビジョニング
- 7. 7 Host A 移動元 仮想マシン Host B 共有ストレージ システム ルートFS 移動先 仮想マシン メモリ状態をコピー ライブマイグレーションの仕組み 共有ストレージには FC SANやiSCSI、 NFSが利用可能 仮想化のメリット③ デモ 14
- 8. 8 Host A 移動元 仮想マシン Host B システム ルートFS 移動先 仮想マシン ライブマイグレーション LMデモ環境の仕組み システム ルートFSNFS共有をマウント /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. 9 17※『日経SYSTEMS』2007年6月号 検証ラボを参考 導入・ランニングコスト比較 • ラック型1Uサイズ同士で比較 • クアッドコア×2CPUで8コア → 16VMまで動作可能 と仮定 – 負荷が低い処理の場合、さらにVM数を追加可能 • 電力消費は安定化電源のため負荷率に大きく影 響されないと仮定 • 発熱量はマシン室の冷却等に影響するが、ここで は考慮に入れていない • 電気代は1A(1000W)あたり月額3000円と仮定 仮想化のメリット④ 仮想化ソフトウェア選択のポイント
- 10. 10 VMware • VMware ESX Server – 実績が一番多い – Virtual Centerによる管理が（ほぼ）必須 – ライセンス・保守料が高額 • VMware ESXi – 無償で利用可能 – サービスコンソール無し（ローカル処理不可） – お試し、スタンドアロン利用には耐えるか 19 Xen • 現在、最も注目されている – 本格導入事例（カシオ計算機、パイオニア等） – 低コストソリューション • Windowsも稼働 – ゲストOS用ドライバの提供 – ライブマイグレーションのサポート（v3.1以降） • いくつかの課題も – UNIX/Linux系の知識が必要 – ディストリビューションが多く、互換性の欠如 – 定番管理ツールが無い 20
- 11. 11 Hyper-V • Windows Server 2008から正式サポート – 比較的低価格 – OS標準の強み？ – System Centerによる統合管理 • これからの課題 – 技術的評価検証 – 実績作り 21 現時点での比較評価 実績 機能 運用管理 技術力 導入コスト ランニン グコスト VMware ◎ ○ ○ ○ △ △ Xen ○ ○ ？*1 ○*3 ◎ ○ Hyper-V △ ○ ？*2 ○ ○ ○ 22 *1 標準ベースの運用管理作り込みの可否 *2 System Centerによる統合管理が未知数 *3 オープンソースによる開発
- 12. 12 事例のご紹介 事例の概要 • パイオニアシェアードサービス株式会社様 システム環境移行 – Windows・Linux等でシステム構築済み – VMwareの導入実績あり • システムリプレースのタイミングで仮想化環境 を構築・移行 ‒ SLES10 SP2+Xenを採用 • 今後、Windowsサーバも含めた既存システム および新規システムも随時仮想化環境に移 行予定 24
- 13. 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. 14 設計のポイント キャパシティプランニングと ハードウェアの選定 27 稼働状況の調査 • 特別なツールは不要 – OS標準の性能測定ツールで十分 – Windows：パフォーマンスモニタ – Linux：sarコマンド • ある程度以上の期間で取得すること – 最低でも1ヶ月の負荷変動を調査 – 時期により負荷が変わるのであればピークに 合わせて取得できるのが望ましい 28
- 15. 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. 16 ストレージの選定 • 最終的にFC SANを採用 – 高い性能 – ハードウェアのスナップショット機能 – レプリケーション（将来的に） • ストレージでのチャレンジ – パフォーマンスがあまり要求されない部分には iSCSIを使用 – SLES10+iSCSI Enterprise Targetによるソフト ウェアiSCSIターゲットを構築 31 多重化による冗長構成 • VMの多重化とハードウェアの多重化を効 果的に組み合わせる • VMの冗長化 – ライブマイグレーション経路の確保 – Heartbeat2を使用し、仮想マシンの監視による 自動再起動 • ハードウェアの多重化 – 構成の多重化と60%ルール – 障害発生時でも縮退運転可能 32
- 17. 17 障害対策 • 設計段階で極力単一障害点を排除 – エンクロージャ：もう一方のエンクロージャへブ レードを移行 – ブレード：HA監視で高速に再起動 – ネットワーク：NICのボンディングで多重化 – スイッチ：二重化 – FC：マルチパス接続（FCスイッチ使用） • ネットワーク対応パトライト – 「構成が地味なので・・」 33 ハードウェア構成の概略 34 FC SAN Web LAN DMZ iSCSI エンクロージャ1 エンクロージャ2 障害発生時はもう一方へVM/ブレードを移行
- 18. 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. 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. 20 ネットワーク設計 • ネットワーク設計で考慮すべきポイント – セキュリティ（DMZとLANの分離） – 運用管理 – 冗長性 • Xen＋VLANで柔軟な構成が可能 – サービスセグメントと管理セグメントを分割 – サービスセグメントをさらに目的別にセグメント 分割 39 構築と運用 既存環境の移行と 仮想化環境運用のポイント 40
- 21. 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. 22 Hinemosの仮想化対応 • 仮想マシンのリソース使用状況の取得 – 管理用Domain 0から情報取得 – CPU・メモリ・ネットワーク • 仮想マシンの管理 – 起動・停止・ライブマイグレーション – VNCによるリモートコンソール接続 43 Hinemos 性能監視画面 44 ← CPU ← メモリ ← ネットワーク ← ディスク
- 23. 23 Hinemos 性能監視設定画面 45 バックアップ • 仮想マシンの特性を活かし、仮想マシンを 稼働させつつシステム全体をバックアップ • ストレージの機能を活用した手順 1. FC SANのハードウェアスナップショット 2. スナップショットをバックアップサーバでマウン ト 3. 中身をバックアップソフトウェアでテープライブ ラリにバックアップ 46
- 24. 24 今後の展開 • Hinemos 協業パートナーとしての展開 – Hinemosを使用したシステム全体のコンサル ティング＋仮想化 – Hinemosの教育・販売・サポート • 仮想化対応について – VMware対応 – Hyper-V対応 47 案件絶賛 募集中 48 お問い合わせ先 「仮想化環境を構築したいが、どこに相談すればいいの？」 まずは我々にご相談ください 日本仮想化技術株式会社 http://VirtualTech.jp/ sales@VirtualTech.jp 050-7571-0584