Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

仮想化専門コンサルタントが教える「成功する仮想化導入のポイント」

1,317 views

Published on

講師:日本仮想化技術 宮原
日時:2013/7/26
アジェンダ:
仮想化技術の現状
仮想化環境設計の基礎
仮想化環境のパフォーマンス
ストレージ
仮想化環境の運用管理
クラウドの活用

Published in: Technology
  • Be the first to comment

仮想化専門コンサルタントが教える「成功する仮想化導入のポイント」

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

×