仮想化専門コンサルタントが教える「成功する仮想化導入のポイント」
•Télécharger en tant que PPT, PDF•
3 j'aime•1,995 vues
講師：日本仮想化技術 宮原 日時：2013/7/26 アジェンダ： 仮想化技術の現状 仮想化環境設計の基礎 仮想化環境のパフォーマンス ストレージ 仮想化環境の運用管理 クラウドの活用
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
En vedette
En vedette (10)
Similaire à 仮想化専門コンサルタントが教える「成功する仮想化導入のポイント」
Similaire à 仮想化専門コンサルタントが教える「成功する仮想化導入のポイント」 (20)
Plus de VirtualTech Japan Inc.
Plus de VirtualTech Japan Inc. (20)
Dernier
Dernier (9)
仮想化専門コンサルタントが教える「成功する仮想化導入のポイント」
- 2. 日本仮想化技術株式会社 概要 • 社名：日本仮想化技術株式会社 – 英語名： VirtualTech Japan Inc. – 略称：日本仮想化技術／ VTJ • 設立： 2006 年 12 月 • 資本金： 20,000,000 円 • 本社：東京都渋谷区渋谷 1-8-1 • 取締役：宮原 徹（代表取締役社長兼 CEO ） • 伊藤 宏通（取締役 CTO ） • スタッフ： 9 名（うち、 8 名が仮想化技術専門エンジニアです ） • 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 移行による仮想インフラ再圧 縮 8V2V:Virtual to Virtual
- 10. ストレージの課題と注目技術 一層の大容量化 仮想ストレージ 重複排除 バックアップ／リカバ リ D2D バックアップ バックアップ統合 性能要求の高速化・多 様化 SSD/NAND の採用 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 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. 無停止運用の実現 • 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. 仮想化環境のサイジング 仮想サーバ環境全体のリソース量を算定 – 例）既存環境から仮想化環境への移行 •各リソースの使用状況を調査・予測 – CPU ・メモリ・ストレージ・ネットワーク •リソース使用率評価前にシステム性能が 不足していないか主観的に判断 – 主観的判断：システムが遅くないかどうか – 遅いと感じられる場合はボトルネック調査 18
- 19. 基本的な高速化の手法 • 仮想マシンを増やして負荷を分散 – Web アプリケーションサーバ、メールサーバ などに有効 • マルチプロセス／スレッド処理は CPU 追 加で – 負荷の高いプロセスが並列化できる場合に有 効 • メモリ追加でアプリのチューニング – DB などメモリ上での処理が多いアプリに有効 • ストレージ高速化で I/O 待ちを減らす – メモリを増やしてバッファキャッシュを増や すのも有効 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 をロック – ロックされている間、他の仮想マシンは物理 CPU を使用できない – 物理 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 を兼ねた CNA 搭載製品が標準に – CNA ： Converged Network Adaptor 27 Brocade 社製品 QLogic 社製品
- 29. ストレージ選定 29
- 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