仮想化専門コンサルタントが教える「成功する仮想化導入のポイント」
2 likes763 views
イベント名：書籍出版記念 仮想化技術最新動向セミナー 講師：日本仮想化技術 宮原 日時：2013/4/23 アジェンダ： • 仮想化技術の現状 • 仮想化環境設計の基礎 – 仮想化環境パフォーマンス – ストレージ • 仮想化環境の運用管理 • クラウド活用
仮想化専門コンサルタントが教える「成功する仮想化導入のポイント」
- 2. 日本仮想化技術株式会社 概要 • 社名：日本仮想化技術株式会社 – 英語名：VirtualTech Japan Inc. – 略称：日本仮想化技術／VTJ • 設立：2006年12月 • 資本金：20,000,000円 • 本社：東京都渋谷区渋谷1-8-1 • 取締役：宮原 徹（代表取締役社長兼CEO） • 伊藤 宏通（取締役CTO） • スタッフ：9名（うち、6名が仮想化技術専門エンジニアです） • URL：http://VirtualTech.jp/ • 仮想化技術に関する研究および開発 – 仮想化技術に関する各種調査 – 仮想化技術に関連したソフトウェアの開発 – 仮想化技術を導入したシステムの構築 ベンダーニュートラルな 独立系仮想化技術の エキスパート集団 2
- 3. 会社沿革 • 2001年1月 株式会社びぎねっと 設立 – 代表取締役社長に宮原 徹が就任 – Linux/OSS技術者教育を中心に事業を展開 • 2006年1月 （株）びぎねっと 年間新規事業開発テーマを「仮 想化技術」に設定 – 日本で初めてXen上でWindowsの動作に成功 • 2006年12月 新規事業会社として「日本仮想化技術株式会社 」を設立 – （株）びぎねっとの兄弟会社として設立 – 代表取締役社長に宮原 徹、CTOに伊藤 宏通が就任 • 2008年8月 第三者増資を行い、資本金を1425万に増資 • 2012年5月 第三者増資を行い、資本金を2000万に増資 • 2012年5月 オフィスを渋谷区渋谷1-8-1 第3西青山ビルに移転 3
- 4. 代表略歴 • 本名：宮原 徹 • 1972年1月 神奈川県生まれ • 1994年3月 中央大学法学部法律学科卒業 • 1994年4月 日本オラクル株式会社入社 – PCサーバ向けRDBMS製品マーケティングに従事 – Linux版Oracle8の日本市場向け出荷に貢献 • 2000年3月 株式会社デジタルデザイン 東京支社長および 株式会社アクアリウムコンピューター 代表取締役社長に就任 – 2000年6月 （株）デジタルデザイン、ナスダック・ジャパン上場 （4764） • 2001年1月 株式会社びぎねっと 設立 • 2006年12月 日本仮想化技術株式会社 設立 • 2008年10月 IPA「日本OSS貢献者賞」受賞 • 2009年10月 日中韓OSSアワード 「特別貢献賞」受賞 4
- 5. 導入・移行 仮想化環境構築をトータルサポート 設計 • 戦略立案 – コスト削減、社内標準化、将来プランのコンサルティング • 設計 – 要求仕様の策定 – サーバ、ストレージからネットワークまでアプリケ ーションまで考慮した設計最適化 – キャパシティプランニング（ベンチマーク） • 導入 – 仮想化ソリューションパッケージの提供 – 仮想化統合（P2V既存環境移行） • 運用保守 – エンジニア教育 – 技術サポートの提供 – OSSソースコードレベルサポート 運用保守 ベンダーニュートラルなワンストップ・サポートをご提供 5 戦略立案
- 6. 本日のアジェンダ • 仮想化技術の現状 • 仮想化環境設計の基礎 – 仮想化環境のパフォーマンス – ストレージ • 仮想化環境の運用管理 • クラウドの活用 6
- 7. 仮想化技術の現状 7
- 8. サーバー仮想化は普及段階に • ハードウェアの仮想化最適化 – マルチコアCPU・大容量メモリ搭載 • 大規模なシステムほど仮想化に移行済み – 中小規模システムの仮想化移行フェーズに – クラウドサービス利用も促進 • 仮想化の導入よりも運用管理に悩み – 性能不足・容量不足 – 障害対応・BCP対応 • 一層のランニングコスト削減要請 – 省電力サーバーへの変更による電力コスト削減 – 高集約環境へのV2V移行による仮想インフラ再圧縮 8
- 9. ハイパーバイザーの最新動向 • VMware vSphere 5でのライセンスの変更 – 仮想マシンに割り当てたメモリ容量による課 金体系に変更 • 不評だったためvSphere 5.1から取りやめ – ホスト数が多いとコストがネックに • Hyper-V 2012の登場 – Windows Server 2012に搭載 – 機能面でvSphereを追従 – Windows多用の場合、コスト面でメリット 9
- 10. ストレージの課題と注目技術 一層の大容量化 仮想ストレージ 重複排除 バックアップ／リカバリ D2Dバックアップ バックアップ統合 性能要求の高速化・多 様化 SSD/SSSの採用 SANの高速化 分散ストレージ BCP対策 遠隔複製機能 クラウドストレージ 10
- 11. ネットワークの課題と注目技術 通信量の増加 10Gイーサネット InfiniBand 仮想ネットワークの一元 管理 分散仮想スイッチ OpenFlow ファブリック BCP対策 高速WAN モバイル 高速ワイアレス通信 11
- 12. 仮想化環境設計の基礎 12
- 13. 仮想化環境設計の基本方針 • 複数サーバで負荷分散と冗長化を図る – 無停止運用、HA（高可用性）構成を実現 – サーバ単体性能は追求しない • ネットワークは役割別にセグメントを分割 • ストレージは容量、速度、耐障害性、コス トのバランスを – バックアップ／リカバリも考慮して 13
- 14. 構成例 14 仮想マシンホスト 仮想マシンホスト ストレージ ストレージ用 管理用 ライブマイグレーション用 管理端末 クライアントネットワーク ネットワークは 少なくとも4系統は 考える必要がある
- 15. 無停止や耐障害性設計 • 冗長化・HA構成による耐障害性の向上 – 基本的な設計はこのレベル – 物理サーバーは3台1組構成を基本に • ライブマイグレーションで無停止システム – ハードウェアのシャットダウンを伴うメンテナ ンスもシステムを無停止で実施可能 • ストレージの冗長化も – データのバックアップをしっかりと行う 15
- 16. 障害に強いシステムの実現 • Server Aに障害は 発生した場合 1. Server Aに障害発生 2. VM1をServer Bで 再起動（システムは 共有ストレージ上に） 3. Server A復旧後、 VM1をServer Aに 復帰 16 VM1 VM2 Server A Server B VM1 VM2 Server A Server B VM1 Server A Server B VM2 ライブ マイグレーション 1. 2. 3. 数分程度で フェールオーバー
- 17. 無停止運用の実現 • Server Aをハードウェ ア的に停止してメンテ ナンスしたい場合 1. VM1をServer Bにライ ブマイグレーション（ システムは無停止） 2. Server Aを停止し、メ ンテナンス 3. VM1をServer Aに復帰 17 VM1 VM2 Server A Server B ライブ マイグレーション VM1 VM2 Server A Server B VM1 Server A Server B 停止メンテナンス VM2 ライブ マイグレーション 1. 2. 3.
- 18. 仮想化環境のサイジング 仮想サーバ環境全体のリソース量を算定 – 既存環境から仮想化環境への移行見積もり • 各リソースの使用状況を調査・予測 – CPU・メモリ・ストレージ・ネットワーク • リソース使用率評価前にシステム性能 が不足していないか主観的に判断 – 主観的判断：システムが遅くないかどうか – 遅いと感じられる場合はボトルネック調査 18
- 19. 基本的な高速化の手法 • 仮想マシンを増やして負荷を分散 – Webアプリケーションサーバー、メールサーバ ーなどに有効 • マルチプロセス／スレッド処理はCPU追加で – 負荷の高いプロセスが並列化できる場合に有効 • メモリ追加でアプリのチューニング – DBなどメモリ上での処理が多いアプリに有効 • ストレージ高速化でiowaitを減らす – メモリを増やしてバッファキャッシュを増やすの も有効 19
- 20. CPUのサイジング • 仮想化のCPUオーバーヘッドは10%程度 • 旧世代CPUから新世代CPUへの移行に より性能アップ • 両者が打ち消し合うため、新旧のクロッ ク性能は同じと考える • CPU使用率が計測できる場合は平均使 用率、あるいは最大使用率で必要クロッ ク数を算出 20
- 21. CPUの仮想化 21 OS OS OS OS OS OS OS OS 仮想CPU割当を減らす 物理CPU数を増やす VM1がCPUリソースを専有 VM切替でVM2がCPUリソース確保 or VM1 VM2 VM1 VM2
- 22. CPU利用状況の最適化 • 仮想CPUの割当数だけ物理CPUをロック – ロックされている間、他の仮想マシンは物理CP Uを使用できない – 物理CPU割り当ては時分割で強制的なので、仮 想CPUがIdleでもロックは発生する • ロックを回避し、スループットを向上 – 仮想CPU割当数を減らす – 物理CPU数を増やす（2コア→4コア→6コア→8コ ア→12コア→16コア） 22
- 23. 性能不足時のCPU使用率評価 • 使用率が長時間100%（高原型） – 詳細分析の上、高速化の手法を検討 – CPU増設、負荷分散など • 使用率が特定の時間だけ高い（スパイ ク型） – CPU増設、負荷分散などで対処 – 処理時間帯をずらして時差処理 • 使用率が乱高下（ノコギリ型） – CPU以外のボトルネックを調査 23
- 24. メモリのサイジング • 実際のメモリ使用／空き容量の調査 – 空き容量が不足し、スワップイン／アウトが 大量に発生していないかどうかを確認 – 適度なスワップアウトは問題なし • メモリオーバーコミット機能を考慮しない – HAクラスタによるフェールオーバーのため に仮想ホストのメモリは空きが必要 – メモリオーバーコミット機能はメモリ不足時 に仮想マシン自体をスワップアウトする機能 なので実際には必要とならない 24
- 25. ストレージのサイジング • 必要となる容量と性能からストレージの 接続方法およびHDD台数などを割り出す • 必要となる容量は現在の必要容量＋1 年後の増加量で算出 – 不足した場合の対応方法も同時に検討 • 必要となる性能はIOPS中心に – 現在使用しているHDDの台数から簡易算出 – データベース、メールサーバーを中心に – SSDやキャッシュ技術の活用も考える 25
- 26. ネットワークのサイジング • 必要となるネットワーク帯域を試算 – ネットワーク流量の多い特定のサービスは スイッチ、NIC等で実際に計測 • ストレージ接続がiSCSI、NFSの場合、ス トレージ用ネットワーク帯域はストレージ 側のポート数・帯域に合わせて検討 – iSCSI接続はマルチパス接続方式を考慮 26
- 27. 10GbE・FCoE・CNA • 10G Ethernet標準搭載サーバーの増加 • 今後、iSCSIやFCoEのHBAを兼ねたCN A搭載製品が標準に – CNA：Converged Network Adaptor 27 Brocade社製品 QLogic社製品
- 30. ストレージ選定時の考慮点 • 容量 – 今後の増加率の予測も合わせて行う – 無停止増設可能か • 速度 – 使用アプリケーションの読み書き特性を考慮 – SSD／NANDフラッシュ、階層化ストレージ、キャッシュ 技術の活用 • 耐障害性 – 単一障害点の排除 – バックアップリカバリも含めて検討 • ローカルストレージの活用 – 共有の必要がなければ、ローカルの方が高速の場合も – システムとデータの分離 30
- 31. ストレージで考慮すべき機能 • バックアップリカバリー – スナップショットとのバックアップ連動 – リモートバックアップとDR • ストレージ統合 – 複数ストレージの論理集約 – 統合管理 – 冗長性排除 – 階層化 31
- 32. 構成設計 まとめ • 元々のサーバーの利用率や性能が低 ければ、性能設計は緩めでも良い • 集約率と耐障害性は反比例するので、 バランスを考えて • ボトルネックはI/O、特にストレージ – HDD台数追加やSSDの利用を考慮 – 今後は10GbEによるネットワーク構成も 32
- 33. 仮想化環境における運用管理 33
- 34. 仮想化運用管理の基本 • 可能な限り既存の運用管理手法を踏襲 – 仮想化だからといって特別なことは無い – 仮想化することでマシン層とOS層の間に 標準化の線引きが行える – 仮想化レイヤーの監視が増える 34 ←サービス監視 ←OS監視 ←仮想化監視 ←ハードウェア監視
- 35. 仮想化環境における性能監視 • 死活監視だけでなく性能監視も重要 – ボトルネックの早期発見・早期対応 • リソース利用量の60%ルールの徹底 – リソース総容量に対する水準線を決めておく – リソース利用量が水準線を越えたらリソー ス追加を検討 • リソースの逐次強化 – リソース量を順次増やしていくビジネスプロ セス（稟議書→決済）への変革が必要 35
- 36. 仮想マシン管理の注意点 • 仮想マシンの構成変更が容易 – メモリ量などすぐに変えられてしまう – リソース使用量の急激な変動に繋がる • 仮想マシンの追加が容易 – リソース使用量の急激な増加に繋がる – 当初想定していた以上のリソース不足 36 構成・変更管理とリソース容量調整が重要
- 37. 仮想化以外の管理 • システムやミドルウェアの構成管理 – 仮想マシン毎の分離度が高いため、個別の コントロールは行いやすい – 仮想マシンの数が多いと、構成・変更管理 が煩雑になる • ストレージの管理 – スナップショットは便利だが、ストレージ性能 が低下するので注意 37
- 38. クラウドの有効活用 38
- 39. メリットのあるクラウド利用 • 短期の利用 – 「持たない」ことによるメリット • 迅速な配備 – セルフサービスポータル • 大量のリソース要求 – ネットワークトラフィックに注意 • 物理的な分散 – BCPの一手段として 39
- 40. クラウドサービスの落とし穴 • 従量課金 – 特にネットワークトラフィック課金が大きくなる • 決済方法 – 「固定課金」では取られすぎの可能性も • 設計 – 性能が読めない – ネットワーク設計の制約 • 運用管理 – すべてをアウトソースできるわけではない 40
- 41. 発展的ハイブリッド活用 • システム発展に合わせてリソース量調整 • フロー部分はクラウドサービスを利用 • リソース要求が一定量まとまった時に プライベートクラウド化 • 可能な限り両者間の移動が 柔軟に行えることが重要 41 時間経過 ー 量
- 43. 何のためのプライベートクラウドか • コスト削減を目指した仮想化環境構築 • サービスレベルの向上 • レガシーマイグレーション • システムインフラの標準化 • 情報システム部門の省力化 43 ITアーキテクチャの再構築
- 44. プライベートクラウド設計 • 機能要件 – 標準機能とオプション機能の必要性を検討 • 非機能要件 – 構築段階と運用段階のサイジングが重要 • 将来要件 – 標準化 – ○aaS提供 – セルフサービスポータル – ハイブリッドクラウド 44
- 45. 標準機能とオプション機能 • 標準機能 – HA（フェールオーバークラスタ） – ライブマイグレーション • オプション機能 – 性能最適化 • 性能不足に陥ることは少ない？ – 仮想分散スイッチ • 仮想ホスト増加時の現実的な課題 – DR対応 • 回線速度やBCP全体との整合性が必要 45
- 46. サイジングのポイント 厳密な分析の前に概算ベースでのサイジングを • CPU – 現在の使用クロック数×使用率＋α • 概算として使用率30%〜50%程度で計算 • ＋αも仮に3割増し程度？ • メモリ – 現在の使用メモリ量の合算＋α – N+1台でHA用のキャパシティを確保 • N台=必要メモリ総容量÷1台あたりの搭載メモリ量 • ストレージ – 現在の使用データ量の合算＋α 46
- 47. 運用方針の策定 • VMあたりの標準リソース量の決定 – H/Wスペックの個別最適化から標準ベースのシス テム展開への移行 – サイジング情報から平均値、再頻出値を導出 • リソース増強ポリシーの決定 – リソース使用率のしきい値 • 例）ストレージ使用率80%でストレージ増設検討 • 運用監視の統合 – 監視サーバー、ログサーバーなどの導入 • バックアップの統合 47