仮想化専門コンサルタントが教える「成功する仮想化導入のポイント」
Upcoming SlideShare
Loading in...5
×
 

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

on

  • 1,053 views

講師:日本仮想化技術 宮原 ...

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

Statistics

Views

Total Views
1,053
Views on SlideShare
1,049
Embed Views
4

Actions

Likes
3
Downloads
5
Comments
0

2 Embeds 4

https://twitter.com 2
http://virtualtech.jp 2

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

CC Attribution-ShareAlike LicenseCC Attribution-ShareAlike License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

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

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